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Abstract 

The  mission-unique  model  that  has  dominated  the  DoD  satellite  Command  and 
Control  community  is  costly  and  inefficient.  It  requires  repeatedly  “reinventing” 
established  common  C2  components  for  each  program,  unnecessarily  inflating  budgets 
and  delivery  schedules.  The  effective  utilization  of  standards  is  scarce,  and  proprietary, 
non-open  solutions  are  commonplace.  IT  professionals  have  trumpeted  Service  Oriented 
Architectures  (SOAs)  as  the  solution  to  large  enterprise  situations  where  multiple, 
functionally  redundant  but  non-compatible  information  systems  create  large  recurring 
development,  test,  maintenance,  and  tech  refresh  costs.  This  thesis  describes  the  current 
state  of  Service  Oriented  Architectures  as  related  to  satellite  operations  and  presents  a 
functional  analysis  used  to  classify  a  set  of  generic  C2  services.  By  assessing  the 
candidate  services’  suitability  through  a  SWOT  (Strengths,  Weaknesses,  Opportunities, 
and  Threats)  analysis,  several  C2  functionalities  are  shown  to  be  more  ready  than  others 
to  be  presented  as  services  in  the  short  term.  Lastly,  key  enablers  are  identified, 
pinpointing  the  necessary  steps  for  a  full  and  complete  transition  from  the  paradigm  of 
costly  mission-unique  implementations  to  the  common,  interoperable,  and  reusable  space 
C2  SOA  called  for  by  DoD  senior  leaders. 
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CONCEPTUAL  DESIGN  AND  ANALYSIS  OF  SERVICE  ORIENTED 


ARCHITECTURE  (SOA)  FOR  COMMAND  AND  CONTROL  OF  SPACE  ASSETS 


I.  Introduction 


Background 

A  significant  and  continuing  challenge  confronting  the  defense  space  acquisition 
community  is  the  large  cost  of  developing,  testing,  deploying,  and  operating  space 
systems.  The  complexity  of  the  myriad  boosters,  spacecraft  buses,  and  payloads  drives 
much  of  this  cost.  The  potentially  catastrophic  results  of  failure  in  the  space  domain 
contribute  to  a  highly  risk  averse  culture,  further  increasing  costs  through  extreme 
deliberateness  and  cumbersome  mission  assurance  efforts.  In  contrast  to  the 
aforementioned  areas,  however,  the  command  and  control  (C2)  structures  for  space 
systems  typically  rely  on  conventional  information  technologies  that  entail  less  impactful 
risks  should  defects  surface  during  on-orbit  operations.  It  is  surprising,  then,  that 
satellite  mission  ground  segments  have  suffered  from  similar  developmental  and  fielding 
woes  to  space  segments  in  terms  of  out-of-control  cost  growth  and  schedule  delays  (1). 

IT  professionals  have  trumpeted  Service  Oriented  Architectures  (SOAs)  as  the 
solution  to  large  enterprise  situations  where  multiple,  functionally  redundant  but  non¬ 
compatible  information  systems  create  large  recurring  development,  test,  maintenance, 
and  tech  refresh  costs.  Through  the  abstraction  of  platform-specific  applications  into 
generic  services,  the  combination  and  re-use  of  these  services  becomes  possible, 
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ultimately  saving  repeatedly  incurred  costs  that  deliver  no  value-added  functionality.  In 
addition,  SOAs  have  been  praised  for  their  emphasis  on  separating  “business  logic”  from 
the  arcane  details  of  a  particular  programming  language  or  coding  approach,  enabling 
system  flexibility  to  changing  market  conditions  or  business  practices. 

Service  Oriented  Architectures  are  built  around  the  following  tenets: 

•  Discoverable  services  treated  as  black  boxes 

•  Well-defined  standards  for  system/service  interfaces  and  for  data  definitions 

•  Loose  coupling  (minimized  dependencies  between  software  components) 

•  Deliberate  code  separation  between  the  “business  logic”  and  “software  logic”  of 
each  component  service,  allowing  flexibility  and  adaptability  in  mission 
execution. 

Problem  Statement 

The  boutique,  one-off  production  model  that  has  dominated  the  space  C2  community  is 
costly  and  inefficient.  It  requires  repeatedly  “reinventing  the  wheel”  in  order  to  achieve 
mission  success.  The  effective  utilization  of  standards  is  scarce,  and  proprietary,  non¬ 
open  solutions  are  commonplace.  In  a  budget  constrained  environment  and  on  a  wartime 
footing  where  Joint  Force  Commanders  are  demanding  space  capabilities  on  a  much 
more  responsive  basis,  the  space  acquisition  community  must  identify  a  new  model  to 
deliver  effective,  maintainable,  and  extensible  satellite  C2  systems  both  faster  and 
cheaper  than  the  current  paradigm. 
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Research  Objectives/  Questions 

This  thesis  has  two  primary  objectives: 

1 .  Understand  the  current  state  of  Service  Oriented  Architectures  (SOA)  in  satellite 
C2  systems  either  in  current  operational  use,  in  commercial  development,  or 
proposed  architectures  by  commercial  and  government  entities 

2.  Identify  and  assess  a  list  of  common  services  to  be  used  in  a  generic  satellite  C2 
SOA.  Show  the  notional  interactions  and  relationships  between  these  services 
using  DoDAF  version  2  service  views. 

In  order  to  achieve  these  objectives,  the  following  questions  will  scope  and  guide  the 

effort. 

1 .  What  services  are  suitable  for  a  space  C2  SOA  implementation? 

2.  How  can  a  set  of  proposed  Space  C2  services  be  assessed  for  future  acquisition? 

Hypotheses 

Applied  to  the  satellite  C2  domain:  SOAs  can  offer  these  major  benefits: 

•  Re-use  of  existing  common  services  and  data  definitions  across  the  space  C2 
enterprise,  regardless  of  mission  type  or  platform  (positioning/navigation, 
communications,  surveillance,  weather,  space  warning,  space  control,  etc.), 
leading  to  drastic  improvements  in  cost  and  schedule 

•  The  ability  for  C2  systems  to  evolve  gracefully  over  time.  Technology 
refreshment,  hardware  replacement,  and  software  upgrades  can  be  executed  more 
quickly  and  with  less  cost  and  risk  because  of  standardized  interfaces  and 
minimized  dependencies  between  services.  Additionally,  satellite  C2  systems 
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built  as  SOAs  should  have  the  ability  to  readily  adapt  to  changes  in  mission 
taskings,  governing  regulations/policies,  or  organizational  interfaces. 

•  The  ability  to  leverage  web  services  to  deliver  federated  security  management 
across  traditional  network  boundaries  of  like  classification,  allowing  efficient 
information  transfer  to  individuals  and  organizations  with  verified  credentials 

•  Improved  interoperability  with  other  DoD  and  coalition  partner  systems,  better 
enabling  net-centricity  across  the  force. 

Methodology 

To  identify  candidate  satellite  C2  services,  the  methodology  specified  in  the  DoDAF, 
Volume  2  will  be  used  as  a  guide.  Once  a  set  of  services  is  proposed,  an  evaluation 
matrix  will  be  utilized  to  assess  each  service  against  a  set  of  criteria  comprising  the 
widely-accepted  key  organizational  and  technical  benefits  of  implementing  a  SOA. 
Analyzing  the  proposed  services  in  this  way  will  illustrate  whether  or  not  there  is  an 
advantage  to  presenting  satellite  C2  functionality  as  services,  as  opposed  to  the  current 
model  of  mission-unique  implementations. 

Assumptions/Limitations 

This  thesis  examines  service  orientation  as  an  organizing  principle  for  designing  a  cost- 
effective  and  operationally  responsive  enterprise-level  satellite  C2  architecture.  The 
analyses  contained  are  primarily  functional  in  nature,  and  as  such,  the  technical  service 
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design  (enterprise  service  buses,  registries,  interface  definitions  etc.)  will  be  left  to  others 
to  design  and  assess  performance. 

Implications 

Lack  of  responsiveness  to  identified  needs  is  perhaps  the  single  most  important  issue 
facing  the  military  space  community.  In  many  cases  proven  technology  exists  to  meet  an 
urgent  Joint  Force  Commander  (JFC)  need.  However,  high  costs  and  lengthy  fielding 
timelines  nevertheless  leave  the  warfighter  waiting  unacceptably  long  for  required 
capabilities.  Service  Oriented  Architectures,  through  their  reliance  on  accepted 
standards,  their  inherent  adaptability  to  various  missions,  and  their  vast  potential  for  re¬ 
use  can  help  alleviate  the  issue  of  responsiveness  in  space.  If  satellite  C2  development  is 
not  needlessly  reinvented  with  every  new  mission,  cost  and  schedule  control  can  be 
gained,  focusing  on  the  true  challenges  associated  with  a  given  acquisition,  thereby 
allowing  the  needed  capability  to  be  delivered  sooner. 
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II.  Literature  Review 


Chapter  Overview 

The  literature  review  chapter  in  this  thesis  is  intended  to  provide  an  analysis  of  the 
current  state  of  Service  Oriented  Architectures  and  their  potential  application  to  satellite 
command  and  control  implementations.  Initially,  it  will  examine  scholarly  writings  on 
SOAs  in  general,  authored  by  information  technology  professionals  and  leading 
researchers  in  the  field.  Further,  guidance  issued  from  Department  of  Defense  and  US 
Air  Force  senior  leadership  will  be  assessed  to  determine  what  governance  exists 
regarding  SOA  concepts  and  the  associated  implications  on  current  or  future 
development  efforts.  Finally,  it  will  investigate  the  writings  and  conference  proceedings 
of  a  variety  of  satellite  C2  experts  in  the  civil,  defense,  and  commercial  sectors  at  the 
technical,  managerial,  and  executive  levels,  capturing  their  viewpoints  on  the  potential 
benefits  and  challenges  of  implementing  SOA  in  satellite  ground  segments. 

The  Rise  of  SOA  (DCOM,  CORBA,  and  Web  Services) 

SOA  evolved  in  the  late  1990s  and  early  2000s  from  DCOM  (Distributed 
Component  Object  Model)  and  CORBA  (Common  Object  Request  Broker  Architecture), 
two  distributed  architectures  aiming  to  standardize  and  simplify  messaging  between 
software  applications  (termed  objects  under  the  object-oriented  model)  by  establishing 
common  interface  schemas  (2).  DCOM  was  introduced  in  1996  and  works  primarily 
with  Microsoft  Windows  (3).  It  was  used  in  applications  such  as  the  Microsoft  Office 
family  of  products.  DCOM  failed  in  two  areas.  Although  it  has  been  ported  to  other 
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platforms,  it  has  achieved  broach  reach  only  on  the  Windows  platform  (4)  Furthermore, 
DCOM  applications  are  difficult  to  deploy  in  an  environment  where  communications 
must  be  performed  across  firewalls  (4). 

CORBA  also  grew  out  of  the  object  orientation  model,  with  vl  .0  released  by  the 
prolific  Object  Management  Group  (OMG)  in  1991.  1.0  was  not  interoperable  and 
provided  only  a  C  mapping,  so  the  OMG  (Object  Management  Group)  published 
CORBA  2.0  in  1997.  It  provided  a  standardized  protocol  and  a  C++  language  mapping, 
with  a  Java  language  mapping  following  in  1998.  This  gave  developers  a  tool  that 
allowed  them  to  build  heterogeneous  distributed  applications  with  relative  ease.  CORBA 
rapidly  gained  popularity  and  quite  a  number  of  mission-critical  applications  were  built 
with  the  technology.  The  most  obvious  technical  problem  with  CORBA  is  its 
complexity — specifically,  the  complexity  of  its  APIs.  Many  of  CORBA’s  APIs  are  far 
larger  than  necessary.  For  example,  CORBA’s  object  adapter  requires  more  than  200 
lines  of  interface  definitions,  even  though  the  same  functionality  can  be  provided  in  about 
30  lines — the  other  170  lines  contribute  nothing  to  functionality,  but  severely  complicate 
program  interactions  with  the  CORBA  runtime.  Unfortunately,  due  to  the  myriad  IDL 
mappings  required,  CORBA  implementations  could  become  very  complicated  (5).  In  a 
near  mirrored  result  to  that  of  DCOM,  CORBA  was  never  adopted  by  Microsoft 
Corporation,  and  therefore  never  gained  universal  acceptance  within  the  industry  (though 
it  was  and  is  still  widely  used). 
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Remote  Procedure  Call  (RPC)  technologies  like  DCOM  and  CORBA  faced  issues 
involving  resources  and  persistent  connections.  Adding  to  this  was  an  increased 
maintenance  effort  resulting  from  the  introduction  of  the  middleware  layer.  Upon  the 
arrival  of  the  World  Wide  Web,  HyperText  Transport  Protocols  (HTTP)  in  conjunction 
with  the  Internet  Browser  replaced  proprietary  RPC  protocols  used  to  communicate 
between  the  user’s  workstation  and  server  (6).  These  distributed  Internet  architectures 
were  known  as  “web  services.”  Web  Services  became  the  genesis  for  Service  Oriented 
Architecture  in  the  sense  that  they  provided  universally  accepted  means  for  web 
applications  to  have  standard  interface  definitions  and  communicate  with  other 
applications  not  otherwise  a  priori  designed  to  work  together. 

The  World  Wide  Web  Consortium  (abbreviated  W3C,  the  main  international 
standards  organization  for  the  internet)  defines  a  web  service  as  a  software  system 
designed  to  support  interoperable  machine-to-machine  interaction  over  a  network.  It  has 
an  interface  described  in  a  machine-readable  format  (specifically  Web  Services 
Description  Language,  or  WSDL).  Other  systems  interact  with  the  web  service  in  a 
manner  prescribed  by  its  WSDL  description,  with  messages  often  formatted  using  a 
SOAP  (Simple  Object  Access  Protocol)  vocabulary,  typically  conveyed  using  HTTP  with 
an  extensible  Markup  Language  (XML)  serialization  (7).  Web  Services  often  utilize  a 
service  registry  acting  as  a  directory  where  services  can  be  discovered,  described,  and  the 
appropriate  WSDL  interface  fully  defined.  These  service  registries  or  brokers  will 
typically  comply  with  the  Universal  Description,  Discovery,  and  Integration  (UDDI) 


8 


specification  (6  p.  253).  Figure  1  depicts  the  typical  data  flow  and  protocols  associated 
with  Web  Services. 


Service 


\P) 


Web 

Service 


Figure  1:  Typical  Web  Services  Data  Flow  (8) 

The  key  standards  with  web  services  (XML,  WSDL,  and  SOAP)  are  described  in 
greater  detail  below. 

XML  (extensible  Markup  Language): 

XML  is  a  set  of  rules  for  encoding  documents  electronically.  It  is  defined  in  the  XML  1.0 
Specification  produced  by  the  W3C,  and  several  other  related  specifications.  It  is  a 
simple,  very  flexible  text  format  derived  from  Standard  Generalized  Markup  Language 
(SGML,  ISO  8879).  Originally  designed  to  meet  the  challenges  of  large-scale  electronic 
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publishing,  XML  now  plays  an  important  role  in  the  exchange  of  a  wide  variety  of  data 
on  the  web  and  elsewhere  (9). 

WSDL  (Web  Services  Description  Language): 

WSDSL  is  the  most  fundamental  technology  standard  associated  with  the  design 
of  services  (6  p.  457).  A  WSDL  describes  the  point  of  contact  for  a  service  provider, 
also  known  as  the  service  endpoint  or  just  endpoint.  It  provides  a  formal  definition  of  the 
endpoint  interfaces  (so  that  requestors  wishing  to  communicate  with  the  service  provider 
know  exactly  how  to  structure  request  messages)  and  also  establishes  the  physical 
location  (address)  of  the  service.  A  WSDL  service  definition  can  be  separated  into  two 
categories. 

The  Abstract  Description  establishes  the  interface  characteristics  of  the  web 
service  without  any  reference  to  the  technology  used  to  host  or  enable  a  web  service  to 
transmit  messages.  By  separating  this  information,  the  integrity  of  the  service  description 
can  be  preserved  regardless  of  what  changes  might  occur  to  the  underlying  technology 
platform,  promoting  re-use  and  graceful  technology  refresh. 

•  portType:  sorts  the  messages  a  service  can  process  into  groups  of 
functions  known  as  Operations 

o  Operations:  represents  a  specific  action  performed  by  the  service 
■  Messages:  input  and  output  communication  parameters 
required  to  execute  an  operation 
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The  Concrete  Description  connects  the  abstract  part  of  the  Web  Service  to  a 
physical  transport  protocol,  by  defining  the: 

•  Binding:  a  physical  transport  technology(SOAP  being  the  most  common), 

•  Port:  the  physical  address  at  which  a  service  can  be  accessed  with  a 
specific  protocol 

•  Service:  A  grouping  of  related  endpoints  (6  pp.  133-136) 

SOAP  (Simple  Object  Access  Protocol): 

SOAP  is  the  universally  accepted  standard  transport  protocol  for  messages 
processed  by  Web  Services.  It  is  XML-based,  flexible,  extensible,  and  can 
accommodate  sophisticated  message  structures.  Every  SOAP  message  is  packaged  into 
a  container  known  as  an  envelope,  which  is  responsible  for  housing  all  parts  of  the 
message.  Each  message  can  contain  a  header  (an  area  dedicated  to  hosting  meta 
information).  The  actual  message  contents  are  hosted  by  the  message  body,  which 
typically  consists  of  XML  formatted  data.  The  contents  of  a  message  body  are  often 
referred  to  as  the  message  payload  (6  pp.  143-144) . 

A  primary  characteristic  of  the  SOAP  communications  framework  exploited  by 
SOA  is  an  emphasis  on  creating  messages  that  are  as  intelligence-heavy  and  self- 
sufficient  as  possible.  This  results  in  SOAP  messages  achieving  a  level  of  independence 
that  increases  the  robustness  and  extensibility  of  this  messaging  framework — qualities 
that  are  extremely  important  when  relying  on  communication  within  the  loosely  coupled 
environment  that  Web  Services  require.  Message  independence  is  implemented  through 
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the  use  of  header  blocks,  outfitting  a  message  with  the  information  required  for  any 
services  with  which  the  message  comes  in  contact  to  process  and  rout  the  message 
appropriately.  This  alleviates  services  from  having  to  store  and  maintain  message- 
specific  logic,  reinforcing  the  SOA  characteristics  of  reuse,  interoperability,  and 
composability.  The  ultimate  impact  of  this  approach  is  that  Web  Services  can  be 
designed  with  generic  processing  functionality  driven  by  various  types  of  meta 
information  the  service  locates  in  the  header  blocks  of  the  messages  it  receives  (6  pp. 
144-145). 

SOA  can  be  distinguished  from  Web  Services,  in  that  SOA  principles  maintain 
that  the  interface  presented  to  the  user  should  not  require  any  knowledge  of  the  specific 
code  implementation  or  language  used  (as  in  some  Web  Service  RPC  implementations). 
Rather,  the  service  should  be  treated  as  a  black  box  performing  a  useful  function,  with 
straightforward  messages  defined  via  WSDL  (rather  than  calls  or  other  implementation- 
specific  operations  disguised  as  WSDL)  being  the  only  things  to  cross  the  interface, 
making  loose  coupling  more  likely.  Web  Services  are  not  a  euphemism  for  SOA. 
Rather,  “service”  is  the  important  concept.  Web  Services  are  merely  a  set  of  protocols  by 
which  services  can  be  published,  discovered  and  used  in  a  technology  neutral,  standard 
form.  (10) 

Examine  a  case  study  comparing  Web  Services  published  by  two  dotcom 
companies  as  alternatives  to  their  normal  browser-based  access,  enabling  users  to 
incorporate  the  functionality  offered  into  their  own  applications.  In  one  case  it  was 
obvious  that  the  Web  services  were  meaningful  business  services — for  example  enabling 
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the  Service  Consumer  to  retrieve  prices,  generate  lists,  or  add  an  item  to  the  shopping 


cart. 


In  contrast,  the  other  organization's  services  are  quite  different.  It  implemented  a 
general  purpose  Application  Programming  Interface  (API),  which  simply  provides 
Create,  Read,  Update,  and  Delete  (CRUD)  access  to  their  database  through  Web 
Services.  This  implementation  requires  that  users  understand  the  underlying  model  and 
comply  with  the  business  rules  to  ensure  that  your  data  integrity  is  protected.  The  WSDL 
tells  you  nothing  about  the  business  or  the  entities.  This  is  an  example  of  Web  services 
without  SOA  (10).  Although,  as  seen  above,  web  services  can  be  implemented  in  a  non- 
SOA  fashion,  the  inverse  is  not  true.  Web  Services  are  an  inexorable  part  of  SOA 

Key  Attributes  of  SOA 

SOA  builds  upon  web  services  by  placing  a  premium  on  separating  “business 
logic”  from  the  detailed  “plumbing”  code  necessary  to  implement  the  logic. 

Fundamental  to  the  service  model  is  the  separation  between  the  interface  and  the 
implementation.  The  invoker  of  a  service  need  only  (and  should  only)  understand  the 
interface;  the  implementation  can  evolve  over  time,  without  disturbing  the  clients  of  the 
service.  Interestingly,  the  same  interface  can  be  offered  by  many  implementations; 
several  key  benefits  of  service  orientation  derive  from  this  abstraction  of  the  capability 
from  how  the  capability  is  delivered  (11).  A  separate  and  distinct  business  services  layer 
ensures  that  the  business  can  respond  quickly  to  new  opportunities  by  making  changes 
only  to  the  applicable  business  services  without  having  to  change  the  underlying 
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implementation  service  layers,  thereby  minimizing  the  amount  of  SW  maintenance 
required. 

A  service’s  intention  is  to  undertake  certain  functions  to  provide  value  to  the 
business;  its  specification  isn’t  just  the  direct  service  it  provides  but  also  the  environment 
in  which  it  undertakes  those  functions.  A  service  therefore  is  a  discreet  domain  of  control 
that  contains  a  collection  of  tasks  to  achieve  related  goals.  In  a  good  service  oriented 
architecture,  these  often  relate  to  organizational  departments  or  sub-departments  and  their 
functional  tasks  (12  p.  89).  SOA  is  not  just  an  architecture  of  services  seen  from  a 
technology  perspective,  but  the  policies,  practices,  and  frameworks  by  which  we  ensure 
the  right  services  are  provided  and  consumed  (10). 

Service  Oriented  Architecture  does  maintain  several  similarities  with  Object 
Orientation  (00).  Like  objects  and  components,  services  represent  natural  building 
blocks  that  can  be  used  to  organize  capabilities  in  ways  that  are  familiar  to  a  business  or 
organization.  Similarly  to  objects  and  components,  a  service  is  a  fundamental  building 
block  that: 

•  Combines  information  and  behavior 

•  Hides  the  internal  workings  from  outside  intrusion 

•  Presents  a  relatively  simple  interface  to  the  rest  of  the  organism 

Further,  where  objects  use  abstract  data  types  and  data  abstraction,  services  can  provide  a 
similar  level  of  adaptability  through  aspect  orientation  (providing  a  means  for  the 
consistent  handling  of  cross-cutting  concerns,  for  example  the  monitoring  of  business 
activities,  access  control  to  services,  and  reliability  of  message  delivery).  Finally,  where 
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objects  and  components  can  be  organized  in  class  or  service  hierarchies  with  inherited 
behavior,  services  can  be  published  and  consumed  singly  or  as  hierarchies  and  or 
collaborations  (10). 

It  is,  however,  the  consumer-oriented  view  of  service  that  is  central  to  SOA  and 
differentiates  it  from  object  orientation.  In  00,  an  object  represents  what  it  is,  but  in 
SOA,  a  service  represents  how  its  users  wish  to  employ  it  (12  p.  89).  SOA  is  generally: 

•  Based  on  open  standards 

•  Architecturally  Composable 

•  Capable  of  improving  Quality  of  Service  (QoS) 

Further  it  typically  supports,  fosters  or  promotes  (6  p.  55): 

•  Vendor  diversity 

•  Discoverability 

•  Federation 

•  Extensibility 

•  Service-oriented  business  modeling 

•  Layers  of  abstraction  between  business  processes  and  technological 
implementation 

•  Enterprise-wide  loose  coupling 

These  characteristics  of  a  properly  implemented  SOA  lead  to  the  following 
organizational  benefits: 

•  Improved  integration  and  intrinsic  interoperability 

•  Inherent  reuse 
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•  Streamlined  architectures  and  technical  solutions 

•  Return  on  legacy  IT  investments  through  the  employment  of  SOA  adapters 

•  Out  of  the  box  compatibility  with  “best  of  breed  alternatives,”  without  being 
locked  into  one  particular  platform 

•  Standardized  XML  data  representation 

•  Organizational  Agility 

All  this  leads  to  the  bottom  line  that  the  “cost,  effort,  [and  schedule]  impacts  incurred  to 
respond  and  adapt  to  business  or  technology-related  change  is  reduced.  (6  pp.  60-64) 

SOA  as  Policy  with  the  DoD 

As  SOAs  have  gained  prominence  within  private  sector  and  academic  circles,  the 
Department  of  Defense  and  its  subordinate  organizations  have  not  sat  idly  by.  Service 
Oriented  Architectures  are  mentioned  explicitly  in  strategic  guidance  from  the 
department’s  most  senior  officials. 

DoD  Net-Centric  Services  Strategy 

In  March  of  2007,  the  DoD  Chief  Information  Officer  (CIO)  released  a  document 
outlining  his  intent  to  build  upon  the  Department’s  net-centric  strategy  “to  establish  a  net- 
centric  environment  that  increasingly  leverages  shared  services  and  SOAs  that  are: 

•  Supported  by. .  .a  single  set  of  common  standards,  rules,  and  shared  secure 
infrastructure 
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•  Populated  with  [both]  mission  and  business  services  provided  and  used  by  each 

Mission  Area. 

•  Governed  by  a  cross-Mission  Area  board  chaired  by  the  DoD  CIO 

•  Managed  by  Global  Information  Grid  (GIG)  Network  Operations  (13  p.  i). 

The  document  notes  that  “as  existing  threats  facing  the  DoD  evolve  and  as  new 

threats  begin  to  emerge,  a  new  level  of  responsiveness  is  required  from  our  forces.”  It 
further  points  out  that  the  department  has  historically  “focused  on  system  or  platform 
capabilities  rather  than  on  mission  [area]  capabilities,”  resulting  in  “information  silos” 
characterized  by  “multiple  overlapping  implementations,  limited  ability  to  share 
information,  and  a  rigid  set  of  capabilities  that  are  unresponsive  to  the  warfighter’s 
evolving  needs  (13  p.  1).”  In  the  strategy  document,  the  DoD  CIO  looks  to  SOA  to  play 
a  major  role  in  solving  the  above  problems.  SOA  is  identified  as,  “a  way  of  describing  an 
environment  in  terms  of  shared  mission  and  business  functions  and  the  services  that 
enable  them  (13  p.  2).” 

Services  are  described  as  “building  blocks  [that]  will  facilitate  interoperability, 
provide  agility,  and  improve  information  sharing”  for  the  warfighter.  The  CIO  goes  on 
to  predict  that  in  addition  to  SOA  improving  operational  effectiveness,  weapon  system 
acquirers  will  also  benefit.  This  is  attributed  to  “services  providing  a  standards-based 
approach  to  achieve  information  sharing,”  and  because  acquisition  responsiveness  is 
increased  through  “cost  and  resource-effective  reuse  of  capabilities.”  “When  providers 
can  discover  existing  capabilities  offered  as  services,  they  can  significantly  reduce  the 
time  and  cost  to  field  a  new  capability  and  gain  improved  interoperability  ‘out  of  the 
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box.  ’  By  using  these  ‘building  blocks,  the  DoD  can  quickly  adapt  to  accommodate  the 
warfighters’  changing  mission  needs  (13  p.  3).”  Figures  3  and  4,  taken  from  the 
document,  illustrate  the  CIO’s  perspective  on  the  current  information  sharing 
environment  (Figure  3),  in  which  capabilities  are  manifested  through  stove-piped 
platforms,  contrasted  with  the  paradigm  he  seeks  to  implement  through  SOA  (Figure  4), 
where  services  are  represented  as  discoverable  “building  blocks”  ready  to  be  assembled 
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Figure  2:  Current  Information  Sharing  Environment  (13) 
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Figure  3  To-be  Net-Centric,  Service-Oriented  Environment  (13) 

The  strategy  lays  out  a  series  of  goals  on  the  path  to  a  service-oriented  DoD 
information  enterprise.  Examining  each  of  these  goals  in  detail  provides  further  insight 
into  what  aspects  of  SO  A  the  DoD  considers  most  critical: 

1.  Provide  Services :  Make  information  and  functional  capabilities  available  as 
appropriately  secure  services  on  the  network 
The  document  points  out  that  services  can  be  built  or  acquired  in  different  ways,  but  in 
each  case  the  following  actions  must  be  performed  (13  p.  6): 

•  Provide  a  description  of  the  service  and  publish  it  to  an  enterprise  service  registry 

•  Build,  appropriately  secure,  and  operate  the  service 

•  Manage  the  performance  and  lifecycle  of  the  service 
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In  this  context,  services  are  explicitly  broken  down  into  two  categories: 

•  Mission  and  Business  Services 

•  Core  Enterprise  Services 

The  focus  of  this  thesis  shall  be  on  the  operational  employment  and  acquisition  of 
SOA-based  satellite  C2  systems,  and  therefore  the  second  category,  Core  Enterprise 
Services,  will  be  considered  outside  the  scope  of  this  paper.  For  Mission  and  Business 
Services,  the  document  places  responsibility  squarely  on  the  “Business,  Warfighting, 
DoD  Intelligence,  and  Enterprise  Information  Environment  mission  areas  to  define  the 
mission  and  business  processes  along  with  the  specific  information  and  functional 
capabilities  that  support  them  (13  p.  6).”  This  is  a  clear  indication  that  the  DoD  views 
SOA  as  far  more  than  an  information  technology  initiative.  Rather,  it  is  a  means  by 
which  warfighters  and  acquirers  can  free  themselves  from  the  constraints  of  a  particular 
platform  or  implementation,  and  instead  present  capabilities  as  generic  services  for 
discovery  and  utilization  by  anyone.  Additionally,  the  strategy  specifies  that  provided 
services  should  be  “visible,  accessible,  and  understandable.” 

2.  Use  Services :  Use  existing  services  to  satisfy  mission  needs  before  creating 
duplicative  capabilities 

This  goal  is  achieved  when  users  look  first  to  consume  existing  services  when  filling 
capability  gaps.  Regardless  of  whether  one  is  charged  with  acquiring  capability  or 
employing  it,  the  DoD  CIO’s  intent  is  for  DoD  personnel  to  re-use  services  that  have 
already  been  developed. 


20 


3.  Govern  the  Infrastructure^  and  Services:  Establish  the  policies  and  processes 
for  a  single  set  of  common  standards,  rules,  and  shared  secure  infrastructure 
and  services  throughout  the  DoD  Enterprise  to  ensure  execution  enables 
interoperability 

The  strategy  recognizes  that  in  order  to  enjoy  the  efficiencies  gained  through  SOA,  a 
DoD  implementation  must  be  governed  from  the  top  down.  Particularly  during 
acquisition,  standards  should  be  enforced  to  ensure  a  common  approach  and 
interoperability  across  systems  and  mission  areas. 

AF  SOA  Playbook 

A  SOA  “playbook”  drafted  by  the  office  of  the  United  States  Air  Force  (USAF) 
CIO  illustrates  how  the  DoD’s  focus  on  SOA  has  filtered  down  to  the  military 
components  for  further  development  and  implementation.  It  explicitly  maps  SOA-related 
information  technology  “tactics”  to  AF  Mission  Objectives. 

The  document’s  executive  summary  identifies  an  ambitious  set  of  specific  goals 
and  objectives  for  a  successful  SOA  implementation  across  the  Air  Force  enterprise. 

The  AF  CIO  seeks  to  improve  the  way  information  is  delivered  to  users,  promote  re-use 
and  prevent  the  duplication  of  exiting  capabilities,  thereby  slashing  deployment  and 
sustainment  costs.  In  essence,  the  playbook  codifies  the  Air  Force’s  aspiration  to  reap 
many  of  the  benefits  promised  by  SOA  that  are  documented  in  above.  In  describing  the 
AF  SOA  vision,  the  document  states  (14): 
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“A  well  architected  SOA  provides  top  to  bottom  management  visibility  of 
existing  services,  so  one  doesn’t  go  on  a  “scavenger  hunt”  for  any  given 
application.  A  SOA  provides  for  a  more  rapid  method  of  distributing 
applications  and  increased  agility.  By  leveraging  and  reuse  of  existing 
enterprise  software,  infrastructure,  and  networking/bandwidth,  the  costs  of 
custom  integration  and  interoperability  are  lowered.  Manual  tasks  are 
reduced  or  eliminated  (14).” 

The  playbook  recognizes  that  the  process  of  implementing  SOA  across  the  Air  Force  is 
likely  to  be  an  arduous  one.  It  notes  a  series  of  key  challenges  ahead  (14  pp.  3-4): 

•  Acquisition  Force  Transformation 

o  Shifting  technical  development  paradigm  from  systems  to  SOA 
o  Educating  SPOs/PMOs  on  the  process 
o  Acquiring  SOA  skills  from  small,  agile  contractors 

•  Agile  Service  Delivery 

o  Re-engineering  AF  Acquisition  Processes 
o  Dynamic  Testing  -  Re-engineering  AF  Testing  Processes 

•  Initial  Investment  required: 

o  Subject  Matter  Experts  for  upfront  vocabulary  work 
o  Support  to  functional  leads  across  the  service  to  expose  their  data 
o  Support  Acquisition  Community  for  centralized  configuration 
management 
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•  Transitioning  to  a  centrally  managed,  end-to-end,  capability  based,  federated 
infrastructure 

SOA  in  Satellite  C2 

The  SOA  movement  has  not  gone  unnoticed  by  ground  system  experts  in  the 
satellite  command  and  control  community.  The  bulk  of  the  interest  to  this  point  has 
focused  on  using  SOAs  to  efficiently  acquire  and  field  satellite  C2  systems. 

The  National  Aeronautics  and  Space  Administration  (NASA),  facing  uncertain 
budgets  in  out  years  and  a  severely  cost-constrained  environment  in  general  has  been 
particularly  keen  to  find  a  more  cost-effective  model  for  controlling  its  unmanned  space 
systems.  According  to  NASA,  the  Goddard  Space  Flight  Center  (GSFC)  Mission 
Services  Evolution  Center  (GMSEC)  reference  architecture  provides  a  scalable, 
extensible,  ground  and  flight  systems  approach  for  future  missions.  The  architecture 
enables  quick  and  easy  integration  of  functional  components  that  are  selected  to  meet  the 
unique  needs  of  a  particular  mission.  The  architecture  enables  the  addition,  deleted,  and 
exchange  of  components  to  meet  the  changing  requirements  of  missions  as  they  progress 
through  their  lifecycles  and  provides  a  rapid,  flexible,  and  cost-effective  means  to  meet  a 
wide  variety  of  evolving  mission  concepts  and  challenges  (15). 

GMSEC  enables  this  system-level  development  approach  by  maintaining  the 
reference  architecture,  defining  standard  messages,  and  supplying  interface  software. 
GSFC  Information  Systems  Division  and  Mission  Engineering  and  Systems  Analysis 
Division  provide  software  development  of  functional  components.  Missions  then  select 
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those  components  that  best  fit  their  operational  needs.  By  utilizing  this  approach, 
organizations  can  prepare  a  satellite  C2  system  tailored  to  their  requirements  at  a  lower 
cost  that  is  “out  of  the  box”  interoperable  with  other  GSFC  GMSEC  based  systems. 
Additionally,  as  technology  advances  or  operational  requirements  change,  new 
components  can  be  added  or  existing  components  can  be  swapped  in  and  out  of  the 
system  with  low  risk  and  minimal  integration  effort  (15). 

Although  NASA  uses  the  words  “components”  (vice  services)  in  its  description  of 
GMSEC,  the  architecture  shares  many  SOA  principles.  It  features  plug-and-play 
components,  standard  messaging,  and  a  software  information  bus  (also  known  in  SOA 
parlance  as  an  “enterprise  service  bus”)  (15).  Like  SOA,  it  emphasizes  the 
standardization  of  both  components  (i.e.  services)  and  interfaces.  In  an  American 
Institute  of  Aeronautics  and  Astronautics  (AIAA)  submitted  paper  at  the  7th  Responsive 
Space  Conference,  experts  studying  methodologies  for  improving  ground  segment 
acquisitions  called  GMSEC  a  “good  example”  of  a  SOA-modeled  ground 
implementation.  The  paper  went  on  to  assert  that  GMSEC’ s  message  bus  middleware 
provided  a  serviced-based  interface  between  Satellite  Operation  Centers  (SOCs)  that  was 
automated  and  SOC  agnostic  (16).  GMSEC  has  supported  eight  orbiting  satellites  and  is 
being  applied  to  several  of  NASA’s  future  missions.  NASA’s  ST5  mission  was  its  first 
to  be  fully  GMSEC  compliant.  It  appears  to  be  a  viable  standard  communications 
infrastructure  for  compatible  command  and  control  interfaces,  messaging,  and  data 
formats  (17).  Figure  5  illustrates  GMSEC’s  “plug  and  play”  design  intent.  Figure  6  then 
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depicts  GMSEC’s  ability  to  accommodate  a  variety  of  implementations  to  meet  mission- 
specific  functional  requirements. 


Across  the  country  at  NASA’s  Jet  Propulsion  Laboratory  (JPL)  in  Pasadena, 
California,  researchers  explored  the  benefits  of  implementing  SOA  solutions  for 
organizing  and  making  accessible  the  large  amounts  of  scientific  data  gleaned  from  its 
“A-Train”  constellation  of  earth-observing  and  climate  trending  satellites.  To  simplify 
access  to  large  and  complex  satellite  data  sets  for  climate  analysis  and  model  verification, 
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Paging 


a  service-oriented  architecture-based  tool  was  developed  to  help  study  long-term  and 
global  scale-trends  in  climate,  water  and  energy  cycle,  and  weather  variability  (19). 
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Figure  5:  Open  (non-proprietary)  nature  of  GMSEC 

Historically,  the  volume  and  inhomogeneity  of  the  data  had  been  difficult  or  time 
consuming  to  search  and  acquire,  resulting  in  analyses  that  tended  to  be  small-scale  or 
short-term.  Recognizing  that  web-based  analysis  environments  can  be  rigid  and  limiting 
to  an  external  user,  the  JPL  researchers  identified  the  need  for  well-designed  distributed 
services  so  that  users  can  perform  analysis  in  their  own  familiar  computing  environments 
(19). 
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To  meet  this  need,  the  researchers  created  “voluminous,  merged”  data  sets  and 
provided  server-side  capabilities  developed  to  off-load  processing  and  reduce  the  amount 
of  data  to  be  transferred  to  the  client.  Finally,  multiple  client-side  processing  APIs  were 
developed  to  enable  scientists  to  perform  analysis  of  the  data  from  within  their  own 
familiar  computing  environment  (Java,  Python,  Matlab,  IDL,  C/C++,  and  Fortran90). 
Merging,  clustering,  subsetting,  averaging,  and  summarization  web  services  were  created 
to  enhance  the  accessibility  and  analysis  of  A-Train  Data.  The  developers  believed  a 
major  benefit  of  utilizing  Web  Services  was  the  true  interoperable  nature  of  their 
implementations.  One  set  of  server-side  Web  Services  paired  with  multiple  sets  of  client- 
side  services  enabled  the  use  (and  re-use)  from  multiple  heterogeneous  environments  and 
varying  client  implementations.  In  the  end,  the  researchers  concluded  that  by  developing 
a  service-oriented  architecture  for  discovering,  accessing,  and  manipulating  merged  A- 
Train  data  sets,  they  “strengthened  the  interconnectedness  and  reusability  of  these 
services  across  a  broader  range  of  Earth  science  investigations  (19).”  It  is  not  hard  to 
imagine  similar  benefits  in  a  defense  or  national  security  space  context,  perhaps  to 
improve  access,  analysis,  and  exploitation  of  overhead  imagery  analysis. 

Also  at  the  Jet  Propulsion  Laboratory  but  as  part  of  a  different  activity,  the 
Advanced  Multi-Mission  Operations  System  (AMMOS)  is  looking  to  procure  and  install 
the  Deep  Space  Information  Services  Architecture  (DISA),  an  enterprise  class  registry 
and  repository  for  all  future  Deep  Space  Network  (DSN)  and  AMMOS  SOA 
implementations.  The  organization  is  also  developing  a  Mission  data  Processing  and 
Control  Subsystem  (MPCS),  which  uses  JAVA  and  XML  for  messages  and  a  SOA 
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message  bus  for  communications  management.  Specifications  and  standards  for  these 
efforts  are  homegrown  under  the  direction  of  the  DISA  Chief  Software  Architect  (20). 

NASA  is  not  the  only  federal  agency  looking  to  realize  the  benefits  of  Service 
Oriented  Architectures  for  space-related  applications.  As  described  above,  the 
Department  of  Defense  initiated  policies  directing  its  subordinate  components  to  conform 
to  its  Net-centric  Services  Strategy.  US  Air  Force  Space  Command  (AFSPC),  the 
echelon  within  the  Air  Force  tasked  with  the  acquisition  and  operation  of  space-related 
defense  systems,  has  begun  to  examine  ways  to  more  efficiently  acquire  and  deploy  new 
satellite  C2  platforms.  Accordingly,  it  is  investigating  SOA  as  a  potential  critical  enabler 
of  those  objectives. 

In  a  written  directive  to  his  staff  and  subordinate  commands  in  late  2008,  AFSPC 
Commander  General  Robert  Kehler  highlighted  the  importance  of  establishing  a  common 
satellite  command  and  control  paradigm  and  moving  “expeditiously  toward  open/service- 
oriented.  .  .systems  for  AFSPC  satellite  programs: 

“The  focus  [should  be  on]  developing  more  efficient  SATOPS 
architectures  and  identifying  requirement  commonalities,  enabling 
consolidation  of  functions  and  capabilities,  reducing  duplication  and 
improving  interoperability  at  all  levels. .  .Any  future  AFSPC  SATOPS 
enterprise  architectures  must  not  only  address  an  open  architecture,  but 
also  legacy  system  requirements  and  infrastructures  ensuring  we  provide 
improved  space  situational  awareness,  defensive  space  control,  and 
operational  responsive  space  capabilities,  enabling  AFSPC  to  meet 
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National  Security  Space  objectives  and  Joint  warfighter  operational  needs” 

(21) 

While  giving  an  address  convening  the  2009  Ground  System  Architectures 
Workshop  (GSAW)  conference  in  Los  Angeles,  USAF  Lieutenant  General  Tom 
Sheridan,  Commander  of  the  Space  and  Missile  Systems  Center  (SMC)  and  the  officer 
charged  with  overseeing  Air  Force  space  acquisition  efforts  on  behalf  of  AFSPC,  echoed 
Gen  Kehler’s  vision  of  ground  systems  being  able  to  interoperate  effectively  and  deliver 
capability  to  the  warfighter  at  the  “speed  of  need.”  In  particular,  he  noted  the  imperative 
to  develop  an  open,  efficient,  service-oriented  architecture  with  shared  commonalities 
across  platforms.  The  goal,  he  said,  should  be  consolidation  of  functions  and  capabilities 
via  non-proprietary  implementations,  eliminating  redundancies  and  duplication  of  work. 
Lt  Gen  Sheridan  declared  that  any  future  AFSPC  satellite  operation  enterprise 
architecture  must  address  not  only  this  need  for  openness  and  interoperability  going 
forward,  but  should  also  be  backwards  compatible  with  existing  legacy  systems  (22). 

Clearly,  in  the  eyes  of  Air  Force  senior  space  leadership,  the  days  of  closed, 
stove-piped,  and  redundant  systems  are  over  for  space  system  ground  architectures.  The 
DoD  Operationally  Responsive  Space  (ORS)  office,  an  organization  reporting 
administratively  to  the  DoD  Executive  Agent  for  Space  and  chartered  expressly  to 
improve  the  responsiveness  of  the  department  in  providing  needed  space  effects  to  the 
warfighter,  is  also  aggressively  pursuing  mechanisms  for  rapidly  constituting  ground 
segments  for  DoD  space  capabilities.  ORS  identifies  SOA  as  a  preferred  means  to  meet 
its  goal  of  developing  what  it  terms  a  “responsive  ground  system  enterprise.”  The 
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office  is  supporting  activities  to  establish  a  compatible  architectural  framework  for 
satellite  operations  (17),  and  has  invested  in  initiatives  across  the  three  services  (Air 
Force,  Army,  and  Navy)  as  well  as  other  agencies  like  NASA  and  the  National 
Reconnaissance  Office  (NRO). 

Key  capabilities  for  the  2015  timeframe  include  autonomous  operations  for 
multiple  constellations  of  small  satellites;  synchronization  of  ORS  assets  with  other 
available  capabilities;  payload  tasking  and  request  tracking  through  a  simple  user 
interface;  standard  vehicle  maintenance;  payload  mission  planning;  standard  command 
and  control  of  the  spacecraft  through  ground-based  and  space-based  relay;  collection  of 
telemetry  and  mission  data  through  ground-based  and  space-based  relay;  processing  and 
dissemination  of  telemetry  and  mission  data  to  joint  force  commanders  or  provision  of 
direct  downlink  to  a  warfighter  in  theater;  and  rapid  transition  of  spacecraft 
demonstrations  and  prototypes  to  operational  use  (17). 

In  addition,  a  number  of  ancillary  needs  are  being  considered.  For  example, 
according  to  ORS  the  ground  system  enterprise  should  incorporate  a  modular  open- 
system  architecture  to  promote  innovation,  standardization,  and  nonproprietary 
development.  It  should  connect  to  exercise  and  war-game  engines  and  integrate  with  the 
global  information  grid.  It  should  allow  autonomous  mission  planning,  data  processing, 
and  data  distribution  and  support  system-level  testing.  It  should  incorporate  a  responsive 
information  assurance  program,  a  responsive  configuration  management  process,  and  a 
responsive  frequency  management  system.  It  must  support,  at  multiple  levels  of  security, 
ORS  missions  involving  electro-optical/infrared  systems,  non-imaging  infrared  systems, 
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signal  intelligence,  synthetic  aperture  radar,  space  and  terrestrial  situational  awareness, 
mobile  communications,  and  blue-force  tracking.  Lastly,  it  must  assign  sufficient 
network  priority  to  ORS  missions  to  expedite  the  upload  of  mission  tasking  and  the 
download  of  mission  data  (17). 

The  Multi-Mission  Satellite  Operations  Center  (MMSOC)  ground  system 
architecture  has  been  designated  as  the  primary  satellite  command  and  control  capability 
for  Air  Force  missions  within  the  ORS  Office.  The  Block  I  architecture  will  be  used  to 
support  the  STPSat-2  mission  in  2010.  It  is  also  installed  at  one  of  the  satellite  operations 
centers  (SOC-1 1)  at  Schriever  Air  Force  Base  in  Colorado  Springs  to  support  ORS’s  first 
operational  satellite:  ORS-1.  The  Block  II  study  phase  was  initiated  in  early  2009,  in 
keeping  with  the  program’s  incremental  approach  for  yearly  block  upgrades  (17). 

The  MMSOC  Ground  System  Architecture  (GSA)  program’s  end  goals,  design 
methodology,  and  acquisition  strategy  have  much  in  common  with  Service  Oriented 
principles.  The  Responsive  Satellite  Command  and  Control  Division  of  the  SMC  Space 
Development  and  Test  Wing,  in  conjunction  with  its  contractor  team,  developed  a 
strategy  for  implementing  a  published  future  architecture.  The  strategy  employs  an 
evolutionary  model  guided  by  an  open-systems  management  plan  with  interfaces 
controlled  by  an  architecture  services  catalog  and  external  interface  control  document. 
The  open-systems  management  plan  was  based  on  fundamental  open-system  principles: 
establish  business  and  technical  enabling  environments;  employ  modular  concepts; 
employ  business  and  technical  patterns;  designate  key  interfaces;  and  use  open  standards 
for  key  interface  certification  and  conformance.  These  principles,  combined  with  the 
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identification  of  standards  (particularly  for  data  and  interface  control)  and  the  established 
catalog  of  services,  will  allow  the  program  to  work  with  a  range  of  potential  missions, 
reducing  unique  mission  support  requirements  (17). 

Service  Views  in  DoD  Architecture  Framework  (DODAF)  v2.0 

According  to  the  latest  release  (version  2.0)  of  the  Department  of  Defense 
Architecture  Framework,  an  architecture  development  methodology  specifies  how  to 
derive  relevant  information  about  an  enterprise’s  processes  and  business  or  operational 
requirements,  and  how  to  organize  and  model  that  information  (23  p.  48).  The  document 
specifies  in  detail  a  six  step  process  for  developing  architectures.  Further,  it  explicitly 
states,  “the  methodology  described  in  this  section  is  applicable  to  development  of  SOA- 
based  Architectures  (23  p.  49).”  Indeed,  an  entire  service-related  viewpoint  (set  of 
views)  is  detailed  in  Volume  2  (24  pp.  190-206). 

The  following  DoDAF  v2.0  views  will  be  provided  in  this  thesis: 

•  Operational  Viewpoint 

o  OV-5:  Operational  Activity  Diagram 

•  Services  Viewpoint: 

o  SVCV-4:  Services  Functionality  Description 
o  SC  VC-5  :  Operational  Activity  to  Services  Traceability  Matrix 
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III.  Methodology 


This  chapter  will  focus  on  the  methodology  to  be  used  in  answering  the  research 
questions.  What  services  are  suitable  for  a  space  C2  SOA  implementation?  How  are 
they  related?  How  can  they  be  assessed  or  evaluated  for  near-term  implementation? 

Answering  these  questions  will  require  aspects  of  both  service  oriented  design  as 
well  as  service  oriented  analysis.  The  results  will  be  illustrated  utilizing  many  of  the 
DoDAF  service  views  discussed  in  section  2.4.  This  thesis  will  use  a  similar  approach  to 
that  prescribed  within  DoDAF  in  the  development  of  notional  services  for  use  satellite 
command  and  control.  It  will  follow  the  six  step  architectural  development  process 
(23): 

1 .  Determine  the  intended  use  of  the  architecture 

2.  Determine  the  scope  of  the  architecture 

3.  Determine  the  data  required  to  support  architecture  development 

4.  Collect,  organize,  correlate,  and  store  architecture  data 

5.  Conduct  analyses  in  support  of  architecture  objectives 

6.  Present  results  in  accordance  with  decision  maker  needs 

With  respect  to  defining  services,  the  methodology  specified  in  the  DoDAF,  volume  2, 
will  be  used  as  a  guide.  The  following  steps  can  be  taken  to  capture  Services 
information  to  support  the  intended  purpose  of  the  architecture: 

•  Identify  and  capture  the  capabilities  supported  or  provided  by  the  services 
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•  Identify  and  capture  the  operations,  business  functions  and  activities  supported  or 
automated  by  the  service 

•  Identify  and  capture  the  Organization  responsible  for  providing  the  services 

•  Using  the  Service  Description,  capture  the  information  to  be  consumed  by  the 
service  and  the  information  that  is  being  produced  by  the  service  (24  p.  99) 

As  this  thesis  aims  primarily  to  specify  these  services  from  a  functional  rather 

than  technical  standpoint,  subsequent  steps  of  this  process  (associated  with 
physical/logical  interfaces,  performance  requirements,  etc.)  will  be  left  to  future 
researchers. 

While  defining  a  set  of  services  and  their  interactions  (as  described  above)  is  a 
worthwhile  and  necessary  step,  it  does  not  fully  answer  the  research  question,  particularly 
in  the  area  of  suitability.  In  order  for  a  service  to  be  deemed  “suitable,”  it  must  engender 
the  characteristics  identified  in  Chapter  II  (SOA  Key  Attributes).  If  the  service  cannot 
embody  these  attributes  in  order  to  capture  the  benefits  promised  by  SOA,  then  the 
question  must  be  asked,  “why  go  through  the  trouble  of  converting  the  functionality  to  a 
service  to  begin  with?”  In  analyzing  this  research  question,  this  thesis  will  focus  on 
addressing  the  degree  to  which  satellite  C2  functionality  can  be  converted  and  meet  the 
accepted  description  of  a  bona  fide  SOA  service. 

Selected  SOA  characteristics  will  form  a  set  of  criteria  allowing  for  a  disciplined 
evaluation  of  how  each  identified  service  stacks  up  against  the  inherent  qualities  of  a 
“suitable”  SOA.  The  template  for  this  comparison  can  be  seen  in  Table  1,  and  the  criteria 
are  described  further  below.  In  cases  where  a  particular  approach  is  required  to  achieve  a 
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SOA  benefit  it  will  be  annotated  and  fully  described,  therefore  identifying  the  highly 
impactful  design/development  considerations  for  future  satellite  C2  SOA  efforts. 

Table  1:  Candidate  Service  Evaluation  Matrix 


The  criteria  in  Table  1  are  assembled  from  the  SOA  characteristics  in  Chapter  2  (many 
referenced  from  (6))  and  are  described  in  detail  below: 

•  Level  of  Support  to  the  Mission  (consistency  with  business/ops  processes): 

In  accordance  with  the  “business”  modeling  aspect  of  SOA,  this  criterion  analyzes  the 
consistency  of  the  service  functionality  with  actual  operational  processes  within  the  DoD 
space  enterprise. 

•  Architecturally  Composable  (decompose  into  smaller  or  aggregate  into 
larger  services)? 
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One  of  the  key  characteristic  of  SOA,  as  mentioned  previously,  is  that  services  can  build 
upon  each  other  to  create  aggregate  services.  Likewise,  they  can  be  decomposed  to 
isolate  services  that  best  apply  to  the  objective  of  the  architecture.  This  quality  adds 
flexibility  while  maintaining  standardization  and  reusability. 

•  Level  of  Commonality  Across  Missions 

If  Service  Oriented  Architecture  were  to  benefit  the  Satellite  C2  enterprise  within  the 
DoD,  then  clearly  much  of  the  value  would  come  from  the  potential  for  re-use  across 
missions,  reducing  the  need  for  redundant  development  efforts.  Any  Service  design 
effort,  therefore,  should  look  to  maximize  the  degree  of  commonality. 

•  Level  of  Propriety  (locked  into  vendor-specific  solutions) 

Service  Oriented  Architecture  is  predicated  on  the  idea  that  it  can  bring  long  term 
flexibility  to  an  enterprise.  The  construction  of  services  based  on  actual 
business/operational  processes  and  the  utilization  of  web  service  standards  foster  an 
ability  to  evolve  (and  tech  refresh)  an  architecture  over  time.  They  also  promote  inherent 
interoperability  across  missions.  Proprietary  implementations  undermine  this  construct 
and  the  associated  potential  benefits. 

•  Criticality  of  Performance  (QoS)  Requirements 

Stringent  Quality  of  Service  (QoS)  requirements  complicate  Service  Oriented 
implementations.  The  flexibility  gained  through  generic  messaging  schemes  like  XML 
and  SOAP,  implemented  through  WSDL  interface  definitions  and  aggregated  into  loosely 
coupled  services,  must  be  tempered  by  the  potential  unintended  consequences  of  so  many 
moving  parts.  SOA  vendors  have  recognized  this  issue  and  are  increasingly  offering 
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diagnostic  tools  to  isolate  the  services  causing  performance  issues  (latency,  availability, 
reliability,  etc.)  and  quickly  resolve  the  problem.  Nevertheless,  performance 
requirements  should  be  assessed  on  a  service-by-service  basis  as  one  component  in 
determining  overall  “suitability”  for  that  functionality  to  be  presented  through  a  SOA. 

The  suitability  of  each  set  of  candidate  services  will  be  scored  using  a  Value  Focused 
Thinking  (VFT)  model  with  the  following  measures: 

•  High  Suitability  (HS)  -  Score:  3.0 

A  highly  suitable  score  indicates  a  functionality  that,  with  respect  to  the  indicated 
criterion,  can  be  presented  as  a  service  without  prohibitive  challenges  and  which  is  likely 
to  yield  the  benefits  desired  from  a  SOA  (e.g.  support  to  the  mission,  composability, 
commonality,  openness). 

•  Moderate  Suitability  (MS)  -  Score:  2.0 

A  moderately  suitable  candidate  service  may  have  certain  characteristics  making  its 
associated  functions  challenging  to  implement  in  a  SOA. 

•  Low  Suitability  (LS)  -  Score:  1.0 

A  candidate  service  scored  with  a  low  degree  of  suitability  represents  functionality  that 
(with  respect  to  the  selected  criterion)  is  not  ready  to  be  transitioned  to  a  SOA  in  the  short 
term.  Presenting  this  functionality  in  the  form  of  a  service  would  be  inconsistent  with  the 
current  state  of  technology,  policy,  or  accepted  practice,  and  would  therefore  be 
unrealistic  without  the  presence  of  some  paradigm-changing  enabler. 

In  addition  to  the  scoring  scheme  described  above,  each  criterion  is  weighted 
according  to  its  relative  importance.  Of  the  possible  benefits  the  Department  of  Defense 
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stands  to  yield  from  implementing  a  satellite  C2  SOA,  the  ability  to  re-use  services  across 
multiple  platforms  and  mission  areas  has  the  largest  potential  to  reduce  cost  and  improve 
schedules,  and  is  therefore  highly  weighted.  Similarly,  the  degree  of  dependency  the 
functionality  has  on  QoS  requirements  will  make  implementing  a  service  for  that  function 
significantly  more  challenging;  therefore,  that  criterion  is  also  weighted  relatively  high. 

In  summary,  for  each  criterion,  the  greater  the  impact  for  the  DoD  on  the  overall  SOA 
value  proposition,  the  greater  the  weighting  factor.  The  weighting  factors  are  also 
described  in  Table  1. 

Lastly,  the  results  of  this  service-by-service  evaluation  will  be  summarized  using 
a  SWOT  (Strengths,  Weaknesses,  Opportunities,  and  Threats)  analysis.  The  goal  here 
will  be  to  assess  what  functionalities  are  best  suited  (strengths)  to  an  immediate  SOA 
implementation  and  which  face  significant  challenges  (weaknesses).  Additionally  it  will 
identify  any  enablers  (opportunities)  that  can  be  put  in  place  to  better  facilitate  a 
transition  to  SOA,  and  what  external  or  institutional  impediments  (threats)  exist  against 
SOA  principles. 

Both  the  VFT  and  SWOT  analyses  will  be  performed  by  a  subject  matter  expert 
with  experience  in  the  acquisition  (design,  development,  fielding,  and  test)  of  satellite 
ground  systems  as  well  as  having  a  background  in  the  operational  command  and  control 
of  a  wide  range  of  space  assets.  This  ensures  both  the  acquisition  and  operational 
perspectives  are  accounted  for  in  assessing  value  and  identifying  strengths,  weaknesses, 
opportunities,  and  threats. 
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IV.  Analysis  and  Results 


This  chapter  will  utilize  the  methodology  presented  in  Chapter  III  to  analyze  what 
satellite  C2  functionality  can  be  suitably  presented  as  services  in  a  SOA,  and  what 
programmatic  and/or  operational  benefits  might  result.  Figure  7  depicts  the  OV-5 
Operational  Activity  view  for  a  generic  DoD  C2  architecture.  The  high-level  activities 
are  broken  down  as  follows: 

•  Generate  Tasking 

•  Plan  and  Schedule  Satellite  Operations 

•  Execute  Real-time  Satellite  C2 

•  Execute  Tasking 

•  Collect,  Process,  and  Analyze  Data 

•  Create  and  Share  Info  Products 

•  Track  and  Report  Status  of  Mission(s)  and  Operational  Resources 

These  activities  are  generic;  they  are  not  particular  to  a  specific  mission  area, 
platform,  or  implementation.  Following  the  Structured  Analysis  IDEFO  format,  inputs 
are  depicted  entering  a  box  from  the  left  and  outputs  leaving  from  the  right.  Constraints 
and  mechanisms  are  applied  to  a  given  activity  from  the  top  and  bottom,  respectively. 

“The  intent  of  IDEFO  is  to  provide  a  means  for  completely  and  consistently 
modeling  the  functions  (activities,  actions,  processes,  operations)  required  by  a  system  or 
enterprise,  and  the  functional  relationships  and  data  (information  or  objects)  that  support 


39 


the  integration  of  those  functions  (25).”  While  more  recent  modeling  languages  exist 
(Unified  Modeling  Language,  System  Modeling  Language,  etc.),  given  its  emphasis  on 
functionality,  IDEFO  was  appropriate  for  this  analysis. 
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Info  Product  Definitions 
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Figure  6:  Satellite  Operations  OV-5  -  Operational  Activity  Viewpoint 
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Service  Descriptions 


Following  the  methodology  outlined  in  Chapter  III,  a  set  of  candidate  services  for 
satellite  command  and  control  is  presented  below  via  a  SvcV-4  viewpoint  (Services 
Functionality  Description).  Presented  as  a  Taxonomic  Service  Functional  Hierarchy, 
Figure8  shows  a  decomposition  of  service  functions  depicted  in  a  tree  structure. 

The  set  of  services  outlined  is  composable,  meaning  it  consists  of  aggregate 
services  comprised  of  lower-level  component  services.  As  mentioned  previously,  this  is 
an  important  characteristic  of  SOA.  Also  noteworthy  is  set  of  shared  services  seen  on  the 
right  side  of  Figure  8.  These  services  cut  across  multiple  areas  to  provide  reusable 
functionality  to  the  entire  architecture  that  does  not  need  to  be  duplicated  within  each 
function.  The  overarching  candidate  services  are  decomposed  two  levels  deeper.  This  is 
not  deep  enough  to  accurately  convey  implementation  (which  is  not  the  intent  of  this 
thesis),  but  it  does  show  how  satellite  C2  functionality  can  be  organized  into  a  notional 
SOA.  It  is  important  to  note  the  service  functions  identified  in  the  SvcV-4  are  not  newly 
conceived.  Rather,  they  aim  to  consolidate  and  standardize  the  generic  functionality  that 
must  be  performed  by  any  satellite  command  and  control  architecture.  When  organized 
into  a  SOA,  the  intent  is  that  these  functions  become  composable,  discoverable,  and 
interoperable  for  any  given  platform  or  mission,  fostering  reuse.  Further,  the  extensible 
nature  of  SOA  (particularly  its  well  understood  interface  definitions  through  the  use  of 
WSDL),  allows  for  the  development  of  mission-unique  functionality  not  provided  by 
existing  services. 
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Figure  7:  SvcV-4  Services  Functionality  Description  (Taxonomic  Service  Functional  Hierarchy) 
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The  SvcV-5  shows  the  relationship  between  the  operational  activities  depicted  in  the  OV- 
5  and  the  services  identified  in  the  SvcV-4.  The  relationship  between  operational 
activities  and  service  functions  can  be  expected  to  be  many-to-many  (i.e.,  one  activity 
may  be  supported  by  multiple  service  functions,  and  one  service  function  may  support 
multiple  activities). 


Table  2:  SvcV-5  -  Operational  Activity  to  Services  Traceability  Matrix 


SvcV-5:  Operational 
Activity  to  Services 
Traceability  Matrix 

Generate  Tasking 

Plan  and  Schedule 
Satellite  Operations 

Execute  Real-time 

Satellite  C2 

Execute  Tasking 

Collect,  Process,  and 

Analyze  Data 

Create  and  Share  Info 

Products 

Track  and  Report  Status 

of  Mission(s)  and 

Operational  Resources 

Tasking 

Service 

Tasking  Parsing  Service 

X 

I' 

COA  Development  & 

Selection  Service 

X 

Tasking  Generation  Service 

X 

X 

Planning  and 
Scheduling 
Service 

Bus  Ops  Planning  Service 

X 

X 

Payload  Ops  Planning  Service 

X 

X 

Ground  Segment  Planning 

Service 

X 

X 
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O 

to 

X 

-o 

Real-time 

Operations 

Service 

Ground  Segment 
Configuration  Service 

X 

_QJ 

O 

to 

X 

Commanding  Service 

X 

~o 

CD 

g 

£ 

Status  Monitoring  Service 

X 

X 

Data  Storage  Service 

X 

X 

Data  Processing 

Service 

Space  Vehicle  Stored 
Telemetry  Processing  Service 

Q. 

C 

.o 

tj 

c 

X 

Customized  Data  Product 

Generation  Service 

.g 

X 

X 

Data  Playback  Service 

,0) 

to 

X 

Data 

Sharing 

Service 

Data  Product  Hosting  Service 

c 

X 

Data  Product  Posting  Service 

o 

X 

X 

Report  Transmission  Service 

o 

X 

X 

Shared  Services 

Timing  Service 

X 

X 

X 

Resourcing  Service 

X 

X 

c 

X 

Orbit  Analysis  and 
Visualization  Service 

X 

X 

X 

8 

o 

X 

X 

X 

Command  and  Telemetry 
Database  (look-up)  Service 

X 

X 

X 

X 

Document  Viewing  Services 

X 

X 

X 

X 

X 

X 

Information  Assurance 

Service 

X 

X 

X 

X 

X 

X 

Logging  Service 

X 

X 

X 

X 

X 

X 
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A  description  of  each  service  identified  in  the  SvcV-4  is  provided  below.  These 
services,  while  not  described  in  technical  detail,  do  convey  how  a  satellite  C2  SOA  might 
be  functionally  organized.  Additionally,  for  each  set  of  services  (apportioned  by  the  six 
categories  identified  above)  an  analysis  will  be  conducted  identifying  the  associated 
strengths,  weaknesses,  and  required  enablers. 

1.  Tasking  Service 

This  service  identifies  space  tasking  requirements  and  the  associated  constraints, 
prioritizes  those  requirements,  and  develops  Courses  of  Action  (COAs)  in  accordance 
with  those  priorities  and  available  resources.  Finally,  the  service  creates  and  sends  actual 
tasking  orders  to  the  tactical  unit  for  execution.  It  is  comprised  of  three  component 
services  as  described  below: 

1.1.  Tasking  parsing  service 

The  tasking  parsing  service  receives  tasking  requests  from  supported 
organizations,  or  internally  generates  requests  for  standing  taskings,  identifies  the  desired 
effect  along  with  any  constraints  associated  with  the  request.  It  also  prioritizes  all  the 
requests  made  to  the  service  across  the  enterprise  based  on  a  predetermined  schema. 

1.2.  COA  development  &  selection  service 

This  service  evaluates  any  constraints  associated  with  a  request  to  check  for 
validity  and  feasibility.  It  then  checks  resource  availability  (pulling  from  the  resourcing 
service  to  be  discussed  later),  and  develops  a  set  of  operational-level  COAs  that  meet  the 
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tasking  constraints.  Next,  it  assesses  these  CO  As  on  the  basis  of  risk,  consumables 
required,  and  opportunity  cost.  Based  on  this  logic,  the  service  will  select  a  preferred 
COA. 

1.3.  Tasking  generation  service 

The  tasking  generation  service  creates  the  actual  tasking  order  based  on  the 
selected  COA,  transmits  the  order  to  the  tactical  unit(s),  and  updates  the  resourcing 
service  (which  is  enterprise-wide)  to  update  the  future  status  of  the  assets  needed  to 
complete  the  tasking. 

2.  Planning  and  Scheduling  Service 

The  planning  and  scheduling  service  will  plan  and  schedule  satellite  operations, 
either  in  support  of  mission-related  (payload)  taskings  or  spacecraft  maintenance/ 
housekeeping  activities.  It  is  comprised  of  many  secondary  and  tertiary  services,  which 
are  described  in  further  detail.  Because  the  bus  and  payload  for  each  DoD  space  mission 
can  differ  widely,  actual  service  implementations  for  this  functional  area  can  and  should 
vary  accordingly.  Care  should  be  taken,  however,  to  not  duplicate  functionality  and  to 
limit  development  efforts  to  truly  mission-unique  requirements.  Additionally,  the  way 
the  planning  and  scheduling  services  interface  with  enterprise  level  services  should 
remain  standardized. 
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2.1.  Bus  Ops  Planning  Service 


The  Bus  Operations  Planning  Service  focuses  on  generating  command  plans  for 
housekeeping  or  maintenance-related  activities.  It  is  comprised  of  three  component 
services  which  are  further  described. 

2.1.1.  Bus  modeling  service 

This  service  models  the  bus  for  use  by  other  planning  services,  defining  pointing 
capabilities  and  limitations,  thruster  configurations,  power  and  memory  management 
schemes,  etc.  It  is  by  definition  spacecraft  unique,  but  will  follow  standardized 
conventions  for  units,  data  types,  etc. 

2.1.2.  Bus  operations  planning  and  scheduling  service 

This  service  plans  and  schedules  the  bus-related  operations  per  the  spacecraft 
modeling  constraints.  Common  activities  to  plan  can  include: 

•  Bus  on-orbit  recurring  maintenance  (such  as  battery  reconditioning,  reaction 
wheel  momentum  dumping,  eclipse  actions,  etc.) 

•  Memory  management  (ensuring  state-of-health  data  is  stored  and  downlinked 
without  exceeding  limits) 

•  Bus  communications  (transmitter  on/off  times) 

•  Miscellaneous  housekeeping  activities 
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2.1.3.  Bus  Ops  planning/scheduling  product  generation  service 


This  service  generates  products  based  on  the  planning  activities  completed  above. 
These  products  can  include  spacecraft  contact  command  plans,  schedules  identifying 
when  the  ground  will  have  opportunities  to  communicate  with  the  spacecraft,  daily 
mission  plans  identifying  what  activities  will  be  completed  at  what  time,  and  others  as 
required  by  the  mission.  It  can  also  create  files  that  will  be  uploaded  to  the  spacecraft 
for  execution  onboard.  This  service  will  standardize  these  products  across  mission  areas 
where  possible,  and  provide  the  ability  for  unique  extensions  or  additions  where  required. 

2.2.  Payload  Ops  Planning  Service 

This  service  is  focused  on  planning  how  to  fulfill  the  tasking  handed  down  from 
higher  headquarters.  The  tasking  can  be  categorized  in  one  of  several  different  mission 
areas,  and  the  planning  for  each  area  should  be  standardized  across  the  enterprise  to  the 
extent  possible: 

•  MILSATCOM 

•  ISR 

•  Positioning/Navigation 

•  Missile  warning 

•  Space  Control 

•  Other  (R&D,  tech  demo,  etc.) 
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2.2.1.  Payload  modeling  service 


In  a  similar  fashion  to  the  bus  modeling  service,  this  service  models  the  specific 
constraints  and  capabilities  of  the  satellite  payload(s). 

2.2.2.  Payload  operations  planning  and  scheduling  service 

Using  the  information  provided  from  the  payload  modeling  service,  this  service 
plans  and  schedules  payload  operations,  which  will  be  used  to  complete  the  tasking. 

2.2.3.  Payload  operations  planning/scheduling  product  generation  service 

This  service  creates  files,  schedules  and  other  planning  products  associated  with 
the  spacecraft  payload. 

2.3.  Ground  Segment  Planning  service 

Like  the  bus  and  the  payload,  the  equipment  and  personnel  making  up  the  mission 
ground  segment  are  assets  that  must  be  planned  for  and  scheduled.  The  ground  segment 
planning  service  provides  this  functionality. 

2.3.1.  Crew  management  and  scheduling  service 

This  service  manages  personnel  requirements  and  metrics  associated  with  a  given 
mission.  In  an  integrated  architecture,  human  operators,  along  with  their  associated 
functions  and  constraints  should  be  accounted  for  just  as  one  would  account  for  hardware 
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and  software.  This  service  provides  that  functionality  and  ensures  the  information  can  be 
utilized  by  the  rest  of  the  architecture. 

2.3.2.  Ground  equipment  management  and  scheduling  service 

This  service  provides  planning  and  scheduling  functionality  in  regard  to  the  chain 
of  ground  equipment  needed  to  communicate  with  the  on-orbit  asset,  which  can  include 
equipment  located  locally  at  the  Satellite  Operations  Center  (SOC),  the  communications 
paths  carrying  downlink  and  uplink  information  to  and  from  the  remote  antenna,  and  the 
set  of  equipment  at  the  remote  antenna  itself.  The  service  also  plans  and  schedules 
ground  maintenance,  regardless  of  whether  the  activity  is  routine/periodic  or  unscheduled 
in  response  to  a  technical  problem. 

3.  Real-time  Operations  Service 

The  real-time  operations  service  contains  the  set  of  component  services  necessary 
to  conduct  satellite  command  and  control  in  real-time  (meaning  in  active  contact  with  a 
space  asset).  To  conduct  real-time  operations,  it  is  necessary  to  configure  ground 
equipment,  conduct  satellite  commanding,  receive  and  process  ground  and  space  segment 
telemetry,  and  store  data  for  further  analysis.  The  services  providing  this  functionality 
are  discussed  in  greater  detail  below. 

3.1.  Ground  Segment  Configuration  Service 

The  ground  segment  configuration  service  controls  ground  segment  equipment.  It 
configures  and  de-configures  local  HW/SW,  communication  links,  and  antenna  HW/SW. 
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3.2.  Commanding  Service 


This  service  generates  the  uplink  information  for  transmission  to  the  spacecraft. 

It  is  comprised  of  two  component  services  which  send  spacecraft  commands  and  data 
files  respectively. 

3.2.1.  Command  build  service 

The  command  build  service  selects  the  proper  command  from  the  spacecraft 
command  and  telemetry  database,  parameterizes  and  formats  it,  transmits  it  to  the 
spacecraft,  and  keeps  track  of  all  commands  sent. 

3.2.2.  Data  file  upload  service 

The  data  file  upload  service  formats  and  transmits  files  (tables,  flight  software 
updates,  communications  schedules,  etc.)  to  be  uploaded  for  processing  onboard  the 
satellite. 

3.3.  Status  Monitoring  Service 

This  service  monitors  the  ground  and  space  segments  and  provides  processed 
information  in  real-time.  It  does  this  processing  by  processing  telemetry,  displaying  that 
information,  and  providing  notifications  of  alarms,  warnings,  or  other  events  of  interest. 

3.3.1.  Telemetry  processing  service 

The  telemetry  processing  service  processes  raw  telemetry  received  from  the 
spacecraft  (demodulates,  de-multiplexes,  frame  synchronizes,  de-commutates,  etc.). 
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Once  the  raw  telemetry  is  processed  it  is  both  stored  in  raw  form  (utilizing  the  data 
storage  service  below)  and  converted  from  binary  to  meaningful  engineering  units. 

3.3.2.  Real-time  display  service 

This  service  displays  the  engineering-unit  converted  data  to  the  operator. 
Telemetry  is  organized  and  formatted  in  a  user-configurable  fashion  in  order  to  maximize 
operational  suitability  and  overall  functionality. 

3.3.3.  Alarms,  warning  and  events  service 

This  service  monitors  status  of  the  space,  link,  and  ground  segments  and  indicates 
alarms,  warnings,  and  other  events  of  interest.  It  interacts  primarily  with  the  real-time 
display  service  but  also  others  as  needed  (logging  service,  data  product  generation 
service,  etc.). 

3.4.  Data  storage  service 

In  satellite  command  and  control  it  is  almost  always  necessary  to  record  data 
downlinked  from  the  satellite,  primarily  for  use  in  later  analysis,  trending,  or  contingency 
analysis.  This  service  provides  that  functionality. 
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4.  Data  Processing  Service 


This  service  turns  data  into  useful  information.  It  processes  telemetry  that  is  not 
needed  real-time,  and  generates  user-customized  reports  for  the  operator,  engineers,  or 
higher  headquarters.  This  service  also  allows  stored  data  to  be  played  back  through  the 
real-time  operations  service,  which  is  often  useful  in  responding  to  operational 
contingencies. 

4.1.  Space  Vehicle  Stored  Telemetry  Processing  Service 

Not  all  telemetry  is  processed  in  real-time.  Large  volume  information  like  Stored 
State  of  Health  data,  for  example,  is  typically  processed  separately  from  information  that 
needs  to  be  stored  immediately.  Other  information  like  command  histories,  system 
logging  data  etc.  must  be  collected  and  sorted  according  to  groupings  that  are  useful  to 
the  consumer. 

4.2.  Customized  data  product  generation  service 

Once  data  has  been  stored  and  processed  into  useful  information,  that  information 
can  be  used  to  populate  reports.  To  maximize  their  effectiveness,  these  reports  should  be 
tailored  to  the  consumer’s  requirements.  The  below  services  provide  common  types  of 
reports  used  by  satellite  controllers  and  engineers: 

4.2.1.  T rending  report  generation  service 

4.2.2.  Out-of-limits  report  generation  service 

4.2.3.  Operational  report  generation  service  (OPSCAP,  OPREP,  SITREP,  etc.) 
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4.2.4.  Mission-unique  report  generation  service  (extensible  to  meet  an  individual 
mission’s  unique  information  product  requirements) 

4.3.  Data  playback  service 

At  times,  it  can  be  useful  to  playback  data  in  order  to  analyze  something  (a 
telemetry  value  of  interest  at  a  certain  time,  for  example)  that  may  have  been  missed  in 
real-time.  This  service  provides  that  functionality. 

5.  Data  Sharing  Service 

Data  products  lose  their  value  if  they  do  not  reach  a  consumer  that  can  exploit  the 
information  contained  within.  This  service  provides  combination  of  push/pull 
functionality  to  ensure  that  data  is  not  only  available  to  a  wide  range  of  authorized  users, 
but  that  time  critical  products  are  transmitted  directly  to  users  that  need  them. 

5.1.  Data  product  hosting  service 

This  functionality  is  implemented  as  a  standard  web-service  portal,  providing 
secure,  discoverable  data  products  available  to  authorized  users.  It  interacts  with  the  data 
product  generation  service  to  provided  tailored  products  or  reports  to  users. 

5.2.  Data  product  posting  service 

This  service  allows  satellite  operators  and  analysts  to  make  specific  information 
products  available  to  the  data  product  hosting  service. 
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5.3.  Report  Transmission  Service 


In  certain  situations,  it  is  not  sufficient  to  make  data  available  to  users.  For 
example,  higher  headquarters  may  have  a  time  critical  requirement  to  receive  operational 
or  ops  capability  reporting  within  a  specified  time  period  following  an  event.  Likewise, 
users  in  the  field  may  need  to  have  certain  data  pushed  to  them  on  the  fly,  rather  than  take 
the  time  to  log  into  the  data  product  hosting  service  and  pull  it  themselves.  This  service 
provides  the  ability  for  satellite  operators  and  data  analysts  to  transmit  information 
products  directly  to  the  user(s). 

6.  Shared  Services 

One  of  the  key  benefits  of  Service  Oriented  Architecture  is  the  ability  to  prevent 
duplication  of  development  effort  through  the  re-use  of  common  services.  Because  so 
much  of  satellite  command  and  control  relies  on  a  common  underlying  IT  infrastructure, 
many  of  these  functions  can  be  abstracted  and  shared  across  the  enterprise  as  single  or 
multiple-instantiated  services.  This  provides  a  significant  benefit  over  duplicated  and 
non-standard  implementations  in  that  it  provides  a  standard  jumping-off  point  for  basic 
functions,  reducing  both  the  time  and  cost  of  ground  segment  development  efforts. 

6.1.  Timing  Service 

Many  satellite  command  and  control  systems  depend  on  highly  accurate  timing 
sources  (for  example,  information  transmitted  as  part  of  Global  Positioning  System 
[GPS]  UHF  signals).  This  timing  service  utilizes  the  standardized  format  published  in 
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GPS  interface  control  documentation  and  will  make  this  timing  functionality  discoverable 
and  consistent  throughout  the  enterprise. 

6.2.  Resourcing  service 

One  of  the  most  critical  aspects  of  an  enterprise-wide  service  oriented  architecture 
is  keeping  track  of  all  resources.  Information  like  asset  availabilities,  capabilities, 
vulnerabilities  will  be  needed  for  many  of  the  associated  component  services  such  as 
tasking,  equipment  configuration,  operational  reporting,  and  orbit  analysis/visualization. 
The  resourcing  service  will: 

•  Provide  updated  resource  status  (across  the  space  C2  enterprise) 

•  Provide  relevant  information  pertaining  to  all  space  resources 

•  Identify  resources/units  relevant  to  tasking  request 

•  Allocate  resources/units  to  selected  COA 

6.3.  Orbital  Analysis  and  Visualization  Service 

Orbital  Analysis  is  a  fundamental  aspect  of  satellite  command  and  control.  It  is 
used  to  generate  ephemerides,  plan  maneuvers,  avoid  collisions,  maintain  a  constellation 
and  determine  when  a  satellite  will  be  in  view  of  a  target  or  ground  antenna. 

Nearly  as  important  as  these  functions,  orbital  analysis  tools  typically  provide 
means  to  visualize  orbits  and  constellations  and  their  relations  to  antennas  or  targets. 
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This  “common  operating  picture  (COP)”  is  necessary  for  planning  and  decision  making 


purposes. 

In  a  SOA,  a  common  analysis/visualization  service  will  interface  with  the 
resource  database  and  operational  tasking  services.  It  can  be  used  by  the  planning 
service,  and  even  provide  real-time  visualization  during  operations.  Finally,  it  can  be 
used  in  the  generation  of  data  products.  Ultimately,  this  service,  in  conjunction  with  the 
resourcing  service,  will  form  the  basis  for  a  space  COP,  available  to  users,  planners,  and 
decision  makers  across  the  military.  Components  of  this  overarching  are  identified 
below: 


6.3.1.  Orbit  determination  and  propagation  service 

6.3.2.  Attitude/Pointing  planning  service 

6.3.3.  Maneuver  planning  service 

6.3.4.  Collision  avoidance  service 

6.3.5.  Formation  maintenance  service 

6.3.6.  Access  reporting  service  (both  ground  and  space  targets/antennas) 

6.3.7.  Visualization  service 

6.4.  Command  and  Telemetry  Database  (look-up)  Service 

One  aspect  of  satellite  command  and  control  currently  driving  much  of  the 
mission-unique  ground  system  development  across  the  DoD  is  inconsistent  and  non- 
interoperable  spacecraft  command  and  telemetry  database  implementations.  Seemingly 
each  spacecraft  vendor  and  payload  manufacturer  relies  on  unique  data  typing  and 
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formatting  requirements.  In  turn,  these  requirements  drive  custom  applications  and  the 
associated  coding  efforts  in  order  to  properly  format  and  process  commands  and 
telemetry. 

This  service  provides  a  command  and  telemetry  database  look-up  service  based 
on  a  standardized  data  schema.  While  bus  and  payload  manufacturers  will  continue  to 
have  complete  flexibility  in  defining  their  own  commands  and  telemetry  mnemonics,  the 
data  types  and  formats  associated  with  those  parameters  will  be  constrained  by  a  schema 
governed  at  the  enterprise  level.  That  governance  enables  this  common  service,  which  in 
turn  allows  the  standardization  of  tools  and  applications  required  to  interact  with  a 
mission’s  command  and  telemetry  database. 

6.5.  Document  Viewing  Service 

Planners,  operators,  analysts,  and  users  will  require  the  capability  to  view  data 
products.  This  service  will  leverage  COTS  products  to  provide  mechanisms  to  view  and 
manipulate  these  products.  Ideally,  this  service  will  span  multiple  operating  systems  and 
platforms  (PC,  Macintosh,  UNIX,  Windows,  Linux,  etc.)  to  give  maximum  flexibility  to 
users.  It  will  leverage  the  Application  Programming  Interfaces  (APIs)  inherent  to  the 
COTS  products  to  remain  compatible. 

6.6.  Information  Assurance  Service 

Ensuring  the  security  of  information  is  inherent  to  military  communications. 
Additionally,  commanders  want  the  capability  to  easily  but  securely  share  information 
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across  classification  domains.  This  service  will  leverage  approved  security  controls,  but 
do  so  using  a  web  services  implementation  (similar  to  that  used  by  the  private  financial 
sector).  It  will  provide  the  following  functionality 

•  Identification/Integrity/ A  valability/ Authentication/non-repudiation 

•  Cross  domain  communication,  allowing  for  increased  sharing  of  specified  data 
products 

•  Encryption  (uplink,  downlink,  crosslink,  bulk  encryption,  over-the-air  rekeying) 

6.7.  Logging  service 

As  with  any  IT-centric  system,  logging  functionality  is  essential  to  satellite 
command  and  control  in  order  to  diagnose,  isolate,  and  ultimately  resolve  technical 
issues.  This  is  especially  important  in  a  service  oriented  context,  where  services  can  be 
flexibly  combined  in  an  open  fashion  to  create  composite  services.  Sporadic 
performance  issues  are  likely  to  be  one  of  the  most  significant  challenges  associated  with 
implementing  a  space  C2  SOA,  and  effective  logging  functionality  will  be  key  to 
resolving  them  responsively. 

Candidate  Service  Evaluations  (Value  Focused  Thinking) 

Utilizing  the  methodology  presented  in  Chapter  III,  each  of  the  level  1  and  2 
services  above  was  evaluated  against  a  set  of  weighted  criteria  to  assess  suitability.  The 
results  are  summarized  in  Figure  9,  and  presented  in  detail  in  Table  3.  The  Value 
Focused  Thinking  (VFT)  scoring  model  resulted  in  data  sharing  services  being  rated  most 
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suitable,  with  data  tasking  services  placing  second.  Real-time  operations  services  were 
rated  as  least  suitable. 
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Figure  8:  Satellite  C2  Candidate  Service  Area  Suitability 

The  assessments  performed  as  part  of  this  analysis  were  not  performed  on  an 
individual  mission  area  basis.  No  attempt  was  made,  for  example,  to  differentiate  each 
service’s  suitability  between  the  very  different  ISR  and  MILSATCOM  missions.  Rather, 
since  the  primary  goal  of  SOA  is  to  obtain  commonality,  re-use,  and  interoperability, 
each  candidate  service  should  be  designed  and  assessed  in  the  context  of  the  worst-case 
requirements  across  the  entire  enterprise  for  a  given  functionality. 
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Table  3:  Candidate  Service  Evaluation  Matrix 


Evaluation  Matrix  for 
Candidate  Satellite  C2 
Services 


Weighting  Factor: 


Level  of 
Support  to  the 
Mission 
(consistency 
with 

business/ops 

processes)? 


Architecturally 
Composable 
(decompose 
into  smaller  or 
aggregate  into 
larger  services)? 


Level  of 
Commonality 
Across  Missions 


30.0% 


Level  of 
Propriety 
(locked  into 
vendor-specific 
solutions) 


Criticality  of 
Performance 
(QoS) 

Requirements 


30.0% 


Service  Value 
Focused 
Thinking  (VFT) 
Score 


Overall  VFT 
Score 


I 

1  8 
*  i 


Tasking  Parsing 
Service 


High  Suitability 
3 


High  Suitability 
3 


COA  Development  & 
Selection  Service 


High  Suitability 
3 


High  Suitabi 
3 


Tasking  Generation 
Service 


High  Suitability 
3 


High  Suitabi 
3 


Bus  Ops  Planning 
Service 


High  Suitability 
3 


High  Suitabi 
3 


Payload  Ops 
Planning  Service 


High  Suitability 
3 


High  Suitabi 
3 


Ground  Segment 
Planning  Service 


High  Suitability 
3 


High  Suitabi 
3 


Ground  Segment 
Configuration 
Service 


High  Suitability 
3 


High  Suitabi 
3 


Commanding  Service 


High  Suitability 
3 


High  Suitabi 
3 


Status  Monitoring 
Service 


High  Suitability 
3 


High  Suitabi 
3 


Data  Storage  Service 


High  Suitability 
3 


High  Suitabi 
3 


Space  Vehicle  Stored 
Telemetry 
Processing  Service 


High  Suitability 
3 


High  Suitabi 
3 


Customized  Data 
Product  Generation 
Service 


High  Suitability 
3 


High  Suitabi 
3 


Data  Playback 
Service 


High  Suitability 
3 


High  Suitabi 
3 


Moderate 

Suitability 

2 


High  Suitability 
3 


Moderate 

Suitability 

2 
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Moderate 

Suitability 
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High  Suitability 
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Moderate 

Suitability 

2 


Moderate 

Suitability 
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High  Suitability 
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High  Suitability 
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Moderate 

Suitability 
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Moderate 

Suitability 
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Data  Product 
Hosting  Service 


High  Suitability 
3 


High  Suitabi 
3 


ity 


High  Suitability 
3 


High  Suitability 
3 


Moderate 

Suitability 

2 


Data  Product 
Posting  Service 


High  Suitability 
3 


High  Suitabi 
3 


ity 


High  Suitability 
3 


High  Suitability 
3 


Moderate 

Suitability 

2 


Report  Transmission 
Service 


High  Suitability 
3 


High  Suitabi 
3 
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High  Suitability 
3 


High  Suitability 
3 


Moderate 

Suitability 

2 


Timing  Service 


High  Suitability 
3 


High  Suitabi 
3 
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High  Suitability 
3 


High  Suitability  | 
3 


Resourcing  Service 


High  Suitability 
3 


High  Suitabi 
3 
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High  Suitability 
3 


High  Suitability  | 
3 


Orbit  Analysis  and 
Visualization  Service 


High  Suitability 
3 


High  Suitabi 
3 


ity 


Command  and 
Telemetry  Database 
(look-up)  Service 


High  Suitability 
3 


High  Suitability  | 
3 


Document  Viewing 
Services 


High  Suitability 
3 


Moderate 

Suitability 

2 


Information 
Assurance  Service 


High  Suitability 
3 


Moderate 

Suitability 

2 


Logging  Service 


High  Suitability 
3 


Moderate 

Suitability 

2 


High  Suitability 
3 


High  Suitability 
3 


Moderate 

Suitability 

2 


High  Suitability 
3 


Moderate 

Suitability 

2 


Moderate 

Suitability 

2 
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Candidate  Service  Evaluation  (SWOT  Analysis) 


In  order  to  better  qualify  the  VFT  results  described  above,  A  SWOT  analysis  will 
be  presented  for  the  total  set  of  candidate  services,  followed  by  a  similar  analysis  for  each 
service  area  identified  in  the  SvcV-4. 

Overall  Satellite  C2  SOA  SWOT  Analysis: 

What  common  themes  emerge  across  the  overall  set  of  candidate  services  from 
the  analysis  conducted  in  Tables  3-5  below? 

•  Strengths:  In  general,  all  the  candidate  services  mapped  well  to  actual  or  desired 
operational  practices  and  did  not  introduce  process  inefficiencies.  In  some  cases, 
they  went  beyond  the  state  of  current  satellite  C2  to  realize  senior  leaders’  vision 
about  how  the  DoD  can  operate  more  effectively  in  space.  A  good  example  of 
this  is  the  collective  use  of  the  resourcing,  visualization,  and  data  product 
generation  service  to  provide  operational  and  tactical  commanders  with  an 
updated,  comprehensive,  and  relevant  Common  Operating  Picture.  This 
improved  battlespace  awareness,  combined  with  accurate  models  of  asset 
capabilities  and  limitations,  will  enable  better  COA  selection  and  more  efficient 
tasking  of  space  assets. 

•  Weaknesses:  Mission  Commonality,  Levels  of  Propriety,  and  Quality  of  Service 
characteristics  appear  to  be  the  criteria  most  significantly  contributing  to  the  weak 
suitability  ratings  of  several  of  the  candidate  services.  This  implies  that  for  the 
services  that  were  assessed  to  be  weak  in  these  areas,  the  currently  available 
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technology  and  methodologies  that  would  be  used  to  implement  the  requisite 
functionalities  are  highly  unique,  subject  to  proprietary  implementations,  and 
subject  to  demanding  performance  requirements.  In  regard  to  commonality  and 
propriety,  much  of  satellite  C2  can  be  made  common  across  mission  areas,  but 
there  will  always  be  unique  requirements  exclusive  to  a  given  platform  or  mission 
area  (MILSATCOM,  Position  Navigation  &  Timing,  ISR,  Weather,  etc.). 

Meeting  these  mission-unique  requirements  without  compromising  the 
commonality  of  the  overarching  architecture  is  a  critical  challenge  that  must  be 
overcome  in  order  to  field  an  enterprise  level  satellite  C2  SOA. 

•  Opportunities:  What  factors  can  help  mitigate  the  weaknesses  note  above? 
Foremost,  standards  can  be  developed  and  adopted  across  the  industry  to  greatly 
reduce  proprietary  implementations.  By  definition,  SOA  principles  alleviate  part 
of  this  problem  naturally  (Web  Service  related  protocols  like  XML,  SOAP, 
WSDL,  and  UDDI  registries  help  reduce  the  need  for  proprietary  APIs). 
Nevertheless,  innovations  like  common  schemas  to  standardize  data  types  and 
formats  in  spacecraft  command  and  telemetry  databases  can  go  a  long  way  to 
reducing  many  of  the  cost  and  schedule  drivers  associated  with  ground  system 
development  efforts. 

•  Threats:  The  largest  threat  to  the  notion  of  a  satellite  C2  SOA  is  a  technical 
community  culturally,  programmatically,  and  technologically  committed  to  the 
status  quo.  Senior  leaders  have  clearly  articulated  the  need  for  a  common, 
service-oriented  SATOPS  architecture.  What  remains  is  for  strategic  guidance  to 
be  translated  to  tangible,  sufficiently  funded  architecting,  design,  and 
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development  efforts,  overcoming  the  organizational  inertia  currently  present 
within  the  Space  C2  community.  All  five  commonly  accepted  sources  of 
organizational  inertia  (26)  play  a  role  here: 
o  Distorted  Perception 

■  Myopia  -  According  to  organizational  theory,  the  simplest  source  of 
induced  myopia  is  turnover  (26).  Applied  to  satellite  C2,  if  a  senior 
leader  expects  to  move  to  another  organization  in  the  near  future,  the 
weight  placed  on  the  future  benefits  of  change  may  be  diminished. 

He  or  she  may  instead  focus  their  energy  and  influence  on  high- 
priority,  short-term  problems. 

o  Dulled  Motivation 

■  Direct  Costs  of  Change  -  It  is  possible  to  look  at  this  factor  from  two 
perspectives:  the  government’s  and  the  contractor’s.  In  the  case  of 
govemment-led  change,  it  is  likely  that  change  may  temporarily 
increase  the  risk  of  failure,  disrupt  operations,  and  involve  a  great 
deal  of  expensive  effort.  Change  may  also  imply  the  abandonment  of 
costly  sunk  specific  investments  (expensive  mission-unique  ground 
systems)  (26).  To  the  contractor,  a  shift  toward  common,  re-usable, 
and  standardized  ground  systems  can  mean  a  very  real  impact  to  a 
company’s  profitability  as  less  mission-unique  systems  are  developed 
and  fielded.  In  satellite  C2,  then,  the  industrial  base  has  a  clear 
disincentive  to  promote  concepts  like  SOA. 
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o  Failed  Creative  Response 

■  Reactive  Mind-Set  -  Change  is  inhibited  when  people  adhere  to  the 
view  that  their  problems  are  natural  and  inevitable  (26).  No  one  will 
argue  that  the  space  business  is  not  complex  or  difficult.  Simple  logic 
dictates  then,  that  high  budgets  and  lengthy  budgets  (driven  by 
arduous  design/build  phases  and  rigorous  test  processes)  must 
naturally  follow!  It  is  precisely  this  type  of  thinking,  however,  that 
impedes  the  implementation  of  new  paradigms  to  solve  existing  and 
well-known  problems. 

o  Political  Deadlocks 

■  Organizational  Politics  -  This  is  one  of  the  most  obvious  sources  of 
inertia.  Leaders  rarely  act  to  unseat  themselves  or  to  terminate  their 
own  departments  (26).  In  the  case  of  Satellite  C2,  would  an 
organizational  realignment  lead  to  more  efficient  ground  system 
acquisition  across  the  enterprise?  What  impacts  would  this  have  on 
individual  program  offices  (in  terms  of  budget  and  authority)? 

■  Vested  Values  -  Here  individuals  and  departments  are  taken  to 
have  strong  emotional  or  value  attachments  to  products,  policies, 
or  ways  of  doing  things.  These  vested  values  and  interests  can 
easily  be  the  greatest  impediments  to  change  (26).  Spacecraft 
builders  have  been  creating  their  own  spacecraft  command  and 
telemetry  databases  (including  defining  their  own  data  types), 
forever.  It  has  worked  until  now;  why  risk  change? 
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o  Action  Disconnects: 


■  Leadership  Inaction  -  Although  AFSPC  leadership  has  articulated 
a  clear  vision  for  change,  incentives  have  not  yet  been  altered  and 
relatively  little  direct  action  has  been  taken  (to  create  a  SATOPS 
enterprise  program  of  record,  for  example).  Until  these  things 
happen,  change  will  be  inhibited  (26). 

■  Embedded  Routines  -  The  life  functions  of  an  organization  are  its 
processes — its  ways  of  doing  things.  Complex  processes  possess 
great  inertia  (26).  The  complicated  sets  of  minutia  comprising 
space  acquisitions  (contracting,  budgeting,  program  management) 
are  juggernauts  in  their  own  right. 

Now  that  the  overall  strengths,  weaknesses,  opportunities,  and  threats  have  been 
identified,  a  lower-level  analysis  will  be  performed  for  each  service  area.  Because  the 
threat  rationale  discussed  above  in  detail  is  applicable  to  each  service  area,  the  below 
analyses  will  focus  only  on  the  Strengths,  Weaknesses,  and  Opportunities  components  of 
the  SWOT  model. 

Tasking  Services  SWOT  Analysis: 

•  Strengths:  This  functionality  is  well  suited  to  be  presented  as  a  service.  By  its 
nature,  the  tasking  service  is  mission-focused.  It  is  composed  of  smaller  services, 
and  can  be  implemented  in  a  non-proprietary  fashion  through  the  utilization  of 
web  services. 
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•  Weaknesses:  Because  the  effect  each  mission  area  provides  is  different,  the  level 
of  commonality  and  therefore  re-usability  may  be  somewhat  limited  outside  of  a 
given  mission  area  (it  does  allow,  however,  for  extensive  commonality  within  a 
mission  area,  e.g.  MILSATCOM).  Also,  availability  is  critically  important,  as 
this  service  initiates  the  satellite  C2  process.  Without  it,  space  effects  cannot  be 
achieved. 

•  Opportunities:  Common  data,  nomenclature,  and  formatting  standards  should  be 
implemented  across  the  space  enterprise,  which  will  enable  common  tasking 
request  language  from  joint  force  commanders,  better  CO  A  selection,  and 
standardized  tasking  products  across  a  diverse  set  of  tactical  units.  The  use  of  this 
service  by  supported  commands  should  be  mandated  by  USSTRATCOM  and  the 
Joint  Functional  Component  Commander-Space  (the  supporting  component 
command). 

Planning  and  Scheduling  Services  SWOT  Analysis: 

•  Strengths:  This  functionality  could  be  implemented  as  a  service.  It  maps  well  to 
established  operational  processes,  is  architecturally  composable,  and  does  not  rely 
heavily  on  stringent  performance  requirements. 

•  Weaknesses:  Differences  between  spacecraft  and  payloads  and  the  associated 
potential  for  proprietary  implementations  make  this  a  functionality  highly 
challenging  to  standardize.  Ground  equipment  as  currently  manufactured  can  also 
be  highly  proprietary  and  customized. 
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•  Opportunities:  If  services  are  defined  at  the  appropriate  level  of  granularity  (fairly 
high  in  this  case),  mission-unique  extensions  to  services  can  be  made  relatively 
easily  without  impacting  other  missions.  This  enables  some  degree  of 
commonality,  reusability,  and  interoperability,  with  the  extensions  providing  the 
flexibility  needed  by  individual  missions.  Other  key  enablers  are  the  modeling 
services  contained  within  the  bus  and  payload  planning  services.  Utilizing 
common  data  types  and  nomenclature  for  the  modeling  services  allows  this 
functionality  to  be  abstracted  and  re-used  across  a  wide  array  of  spacecraft  and 
missions  (again  with  the  appropriate  mission-unique  extensions  as  required). 

Real  Time  Operations  Services  SWOT  Analysis: 

•  Strengths:  The  real-time  operations  candidate  services  are  highly  consistent  with 
operational  processes  and  are  architecturally  composable. 

•  Weaknesses:  The  mission-unique  nature  of  today's  satellite  C2  ground  segments 
and  satellites  makes  trying  to  develop  a  common  service-oriented  approach  to 
real-time  operations  very  difficult.  Additionally,  real-time  operations  demands 
high  levels  of  capacity  (bandwidth  requirements  are  ever-increasing),  availability, 
and  reliability,  meaning  any  SOA  implementation  will  not  be  tolerant  of  poor 
QoS. 

•  Opportunities:  Once  again,  standards  (implemented  and  governed  across  the 
enterprise)  are  key  enablers  for  providing  this  functionality  via  services.  While  it 
is  unrealistic  to  expect  every  spacecraft  and  payload  to  be  designed  with  the  same 
commands  and  telemetry  mnemonics,  it  should  be  possible  to  develop  and  enforce 
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standards  with  respect  to  data  types,  formats,  nomenclature,  etc.  Another  enabler 
of  real-time  operations  is  a  common  database  (look-up)  service  for  commands  and 
telemetry.  That  service,  discussed  below,  will  also  rely  heavily  on  common 
standards. 

Data  Processing  Services  SWOT  Analysis: 

•  Strengths:  Potential  exists  to  implement  this  functionality  as  services.  The 
functionality  is  consistent  with  operational  practices,  is  composable,  and  can 
likely  be  implemented  by  any  number  of  COTS  vendors. 

•  Weaknesses:  Processing  stored  telemetry  is  hampered  by  the  same  mission-unique 
aspects  as  real-time  operations.  Additionally,  obtaining  commonality  for  the  data 
product  generation  service  may  require  utilizing  a  standardized  set  of  COTS 
products. 

•  Opportunities:  Similarly  to  real-time  operations  above,  common  data  standards 
will  greatly  facilitate  the  development  of  this  service  by  reducing  the  number  of 
mission-unique  extensions. 

Data  Sharing  Services  SWOT  Analysis: 

•  Strengths:  This  functionality  is  highly  suited  for  implementation  as  a  web  service, 
and  is  already  fielded  in  numerous  applications  across  many  different  sectors. 

•  Weaknesses:  Though  the  advantages  greatly  outweigh  the  disadvantages,  one 
cause  for  concern  is  that  hosting  data  products  and  making  them  available  to 
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multiple  users  is  more  complicated  than  a  point-to-point  implementation.  QoS 
availability,  reliability,  and  capacity  requirements  will  need  to  be  met. 

•  Opportunities:  Shared  services  will  be  key  to  realizing  this  functionality  in  an 
effective  and  secure  fashion.  Of  particular  note  is  the  document  viewing  service 
and  information  assurance  service. 

Shared  Services  SWOT  Analysis: 

•  Strengths:  The  shared  services  in  this  group  represent  functionality  that  is 
common  to  multiple  services.  They  therefore  tend  to  be  inherently  common 
across  mission  areas,  directly  support  operational  practices,  and  can  be 
instantiated  multiple  times  as  parts  of  aggregate  services. 

•  Weaknesses:  Common  standards  represent  the  greatest  challenge  posed  by 
implementing  these  shared  services.  Additionally,  because  these  services  in 
many  cases  act  as  infrastructure  underpinning  other  functionality,  QoS 
requirements  will  be  stringent. 

•  Opportunities:  As  discussed  previously,  common  and  open  standards  are  the  only 
way  to  obtain  true  commonality  available  from  multiple  vendors. 
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V.  Conclusions  and  Recommendations 


Chapter  Overview 

This  chapter  will  summarize  the  conclusions  from  the  analysis  conducted  above, 
characterize  their  significance,  and  will  make  recommendations  for  action  based  on  them. 
Lastly  it  will  suggest  future  avenues  of  research  related  to  Service  Oriented  Architecture 
in  satellite  command  and  control. 

Conclusions  of  Research 

What  conclusions  can  be  drawn  from  the  preceding  analysis?  First,  it  is  clear  that 
not  all  of  the  services  identified  in  Chapter  IV  were  created  equal;  some  are  better  suited 
to  immediate  implementation  than  others.  The  functionalities  associated  with  two  of  the 
areas  discussed  above  are  better  suited  to  be  presented  as  services  in  the  short  term: 
tasking  and  data  sharing.  Posting  and  hosting  data  products  using  web  services  is 
already  ubiquitous  on  the  internet  and  can  be  heavily  leveraged  since  this  functionality  is 
not  at  all  specific  to  the  space  domain.  Next,  the  tasking  service  can  also  be  considered 
more  ready  because  it  is  inherently  conducted  at  the  enterprise  (operational  level);  there 
is  no  need  to  negotiate  a  common  standard  across  multiple  mission  areas  (a  weakness 
definitely  impacting  the  readiness  of  the  other  candidate  services). 

Furthermore,  both  the  data  sharing  and  tasking  services  have  only  moderate 
performance  requirements,  which  are  primarily  focused  on  availability/reliability,  not  on 
capacity  or  dealing  with  high  data  rate  information  streams.  The  proposed  shared 
services  could  be  developed  quickly,  but  are  likely  to  be  dependent  in  the  near  term  on 
proprietary  solutions,  and  are  also  subject  to  stringent  performance  requirements.  These 
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services  would  comprise  the  “infrastructure”  of  the  architecture  and  must  therefore  have 
extremely  high  availability/reliability. 

There  are  significant  challenges  associated  with  developing  common  services  for 
mission  planning,  real-time  operations,  and  data  processing.  The  current  practice  of 
mission-unique  implementations  (often  utilizing  proprietary  products)  is  a  large 
contributor  to  this  reality.  Also  complicating  the  presentation  of  these  functions  as 
services  are  the  associated  stringent  performance  requirements.  These  services  would 
have  to  pass  high  quantities  of  information  reliably,  without  latencies  or  inaccuracies. 

This  can  be  challenging  to  do  within  the  focused  confines  of  a  mission-unique 
development  effort,  to  say  nothing  of  an  enterprise-wide  common  service  architecture. 

Nevertheless,  the  benefits,  of  SOA,  as  outlined  in  Chapter  II,  are  potentially 
impactful  enough  that  it  is  worth  asking  the  question,  how  could  the  DoD  make  SOA 
work  in  space  C2?  What  are  the  enablers  that,  if  in  place,  would  facilitate  a  shift  from  the 
current  way  of  acquiring  and  employing  satellite  ground  systems  to  a  service-oriented 
model,  taking  advantage  of  the  reuse,  interoperability,  and  openness  of  such  a  paradigm? 
Based  on  the  analysis  above,  the  two  most  critical  enablers  for  SOA  Satellite  C2  are: 

•  Enforced  Standards 

•  Implementations  that  prioritize  performance  requirements 

Open  standards  exist  in  the  satellite  C2  community  (the  Object  Management 
Group’s  [OMG]  Consultative  Committee  for  Space  Data  Systems  [CCSDS] 
specifications  are  a  good  example),  but  they  are  used  only  intermittently.  Making  matters 
worse,  even  the  published  standards  too  often  try  to  be  “all  things  to  all  people,”  resulting 
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in  guidelines  that  are  not  truly  prescriptive  in  nature.  Two  implementations  complying 
with  the  same  standard  are  likely  to  be  not  at  all  interoperable.  Furthermore,  industry 
currently  has  little  incentive  to  get  behind  a  common  set  of  standards.  Profit  often  centers 
around  the  development  of  a  unique  or  proprietary  solution  to  meet  a  given  mission’s 
specific  needs.  Companies  subsequently  tout  the  successful  fielding  of  these  solutions 
when  bidding  on  future  business,  and  while  there  is  nothing  inherently  wrong  with  this,  it 
provides  a  disincentive  to  develop  an  industry-wide  architecture.  It  is  important, 
therefore,  that  the  standards  be  downward-directed  and  enforced — they  should  be 
contract  requirements.  To  truly  enable  Service  Oriented  Architecture  in  the  military 
satellite  C2  community,  standards  should  be  developed  that  are  prescriptive,  and  they 
must  be  governed  by  an  organization  that  has  the  authority  and  intent  to  enforce  them. 

Next,  the  community  must  be  confident  that  no  degradation  of  performance  will 
be  incurred  by  implementing  SOA.  While  the  business  case  for  SOA  (in  terms  of  cost 
and  schedule)  is  certainly  attractive,  US  space  capabilities  are  far  too  important  to  the 
national  defense  to  give  up  performance  for  standardization.  Any  SOA  efforts  in  the 
Space  C2  domain  should  place  a  premium  on  ensuring  Quality  of  Service  (QoS) 
requirements  are  identified,  met,  and  validated  as  early  as  possible. 


73 


Significance  of  Research 

Delivering  on-orbit  capabilities  on  time  and  on  schedule  is  the  DoD’s  highest 
space  priority.  The  environment,  complexity,  difficulty  of  access,  and  shear 
technological  challenge  collectively  make  delivering  space  effects  hard.  That  is  precisely 
why,  however,  investigating  Service  Oriented  Architecture  for  satellite  C2  makes  sense. 
On  a  wartime  footing  and  in  a  budget-constrained  environment,  the  DoD  needs  to  spend 
its  dollars  on  truly  advancing  its  capabilities,  not  duplicating  functionality  within  each 
self-contained  mission  area.  For  the  sake  of  the  warfighter  and  the  American  taxpayer, 
the  DoD  needs  to  rapidly  arrive  at  a  common,  interoperable,  open  ground  segment 
architecture,  one  that  is  able  to  standardize  shared  functionality  while  accommodating 
necessary  mission-unique  extensions.  Service  Oriented  Architecture  may  be  one  of  the 
best  mechanisms  available  to  achieve  that  objective. 

Recommendations  for  Action 

The  Air  Force  Space  and  Missile  Systems  Center  (SMC)  should  strongly  consider 

the  use  of  Service  Oriented  Architecture  in  its  development  of  a  compatible  Satellite  C2 

system.  Implementing  a  SOA  not  only  ensures  compliance  with  top-level  DoD  and  Air 

Force  guidance,  but  also  demonstrates  a  commitment  to  open,  interoperable,  and  reusable 

functionality  that  will  ultimately  mean  better  capabilities  delivered  at  faster  speeds.  This 

effort  should  flow  from  the  top  down.  Indeed,  rather  than  allowing  each  mission  area  to 

continue  to  develop  their  own  ground  segments,  SMC  should  realign  organizationally, 

creating  a  directorate  that  is  empowered  and  funded  to  develop,  field,  and  govern  a 

common  Air  Force  satellite  C2  architecture.  This  organization  would  operate  in  much 
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the  same  way  as  SMC’s  Launch  and  Range  System  Program  Office.  An  enterprise 
architecture  should  be  created  that  captures  requirements  for  all  Air  Force  space 
platforms  (both  existing  and  planned)  in  a  single  vision  for  an  interoperable  ground 
segment,  leveraging  the  architecting  efforts  already  underway  by  various  sub¬ 
organizations  within  AFSPC  and  the  DoD.  The  architecture  should  be  based  upon  a 
common  set  of  data  standards,  and  in  this  effort  SMC  should  work  closely  with  the  DoD 
Operationally  Responsive  Space  office,  NASA,  and  the  NRO,  who  have  already  made 
advances  in  this  area. 

A  formal  program  of  record  should  be  created  to  design  and  field  the  capabilities 
identified  in  the  common  satellite  C2  architecture.  This  program  should  solicit  and  select 
candidate  services  from  a  variety  of  vendors,  ensuring  conformity  with  the  enterprise 
architecture,  data  standards,  and  performance  requirements.  The  objective  time  horizon 
for  the  first  block  of  the  common  system  should  be  2020,  with  no  competing  mission- 
unique  ground  systems  in  development  past  2015. 

Recommendations  for  Future  Research 

This  thesis  primarily  focused  on  a  functional  analysis  of  what  services  would  be 
suitable  for  a  Space  C2  SOA.  While  it  recognized  the  need  to  address  service 
performance  requirements,  common  standards,  and  the  actual  technical  design  of  space 
C2  services,  these  efforts  were  left  to  future  researchers.  In  particular,  the  development  of 
common  standards  and  clear-cut  performance  requirements  are  pre-requisites  that  must 
be  completed  before  real  technical  service  design  can  begin  in  earnest. 
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Further  architecting  work  is  also  required.  A  logical  data  model  (DIV-2)  for  a 
satellite  C2  SO  A  should  be  created  prior  to  service  design,  along  with  an  OV-2 
identifying  organizational  need  lines.  These  viewpoints  will  help  identify  the  data  flows 
in  and  out  of  the  web  services,  and  those  will  be  the  providers/consumers  of  the  services. 

Summary 

At  first  glance,  the  DoD  and  the  Air  Force  have  been  speaking  with  one  voice 
with  respect  to  both  Service  Oriented  Architecture  and  Satellite  C2  for  some  time.  The 
guidance  from  senior  leadership  on  SOA  “goodness”  is  unequivocal,  and  most  experts 
would  agree  it  is  in  the  Air  Force’s  best  interest  to  adopt  a  shared,  interoperable  approach 
to  satellite  operations  as  quickly  as  possible.  Why  then,  in  late  2010,  is  there  still  no  clear 
path  to  achieving  a  common,  service-oriented  ground  architecture? 

The  analysis  conducted  in  this  thesis  concluded  that  certain  functionalities  are 
more  ready  to  be  presented  as  services  than  others:  namely  tasking  and  data  sharing.  Due 
to  a  lack  of  agreed-upon  data  standards  that  can  span  mission  areas  and  concerns  about 
the  ability  of  SOA  to  meet  stringent  performance  requirements,  other  space  C2  functions 
are  currently  less  suited  to  service  implementation.  Nevertheless,  if  these  last  two 
enablers  can  be  put  in  place,  the  Air  Force  and  the  DoD  stand  to  reap  significant  cost  and 
schedule  benefits  stemming  from  re-use  and  shortened  developments.  Indeed,  the 
potential  rewards  alone  make  the  construction  of  an  enterprise-wide  Satellite  C2  Service 
Oriented  Architecture  worthy  of  focused  study  and  consideration  at  the  highest  levels  of 
the  Air  Force  and  the  DoD. 
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Appendix  A:  Acronyms 


AF 

Air  Force 

AFSPC 

Air  Force  Space  Command 

AIAA 

American  Institute  of  Aeronautics  and  Astronautics 

AMMOS 

Advanced  Multi-Mission  Operations  System 

API 

Application  Programming  Interface 

C2 

Command  and  Control 

CCSDS 

Consultative  Committee  for  Space  Data  Systems 

CIO 

Chief  Information  Officer 

COA 

Course  of  Action 

COP 

Common  Operating  Picture 

CORBA 

Common  Object  Request  Broker  Architecture 

COTS 

Commercial  Off-The-Shelf 

CRUD 

Create,  Read,  Update,  and  Delete 

DCOM 

Distributed  Component  Object  Model 

DISA 

Deep  Space  Information  Services  Architecture 

DoD 

Department  of  Defense 

DoDAF 

Department  of  Defense  Architecture  Framework 

DSN 

Deep  Space  Network 

GIG 

Global  Information  Grid 

GMSEC 

GSFC  Mission  Services  Evolution  Center 

GPS 

Global  Positioning  System 

GSA 

Ground  System  Architecture 

GSAW 

Ground  System  Architectures  Workshop 

GSFC 

Goddard  Space  Flight  Center 

HTTP 

HyperText  Transport  Protocol 

HW 

Hardware 

IDL 

Interface  Definition  Language 
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ISR 

Intelligence,  Surveillance,  &  Reconnaissance 

IT 

Information  Technology 

JFC 

Joint  Force  Commander 

JPL 

Jet  Propulsion  Laboratory 

MILSATCOM 

Military  Satellite  Communications 

MMSOC 

Multi-Mission  Satellite  Operations  Center 

MPCS 

Mission  data  Processing  and  Control  Subsystem 

NASA 

National  Aeronautics  and  Space  Administration 

NRO 

National  Reconnaissance  Office 

OMG 

Object  Management  Group 

00 

Object  Orientation 

OPREP 

Operational  Report 

OPSCAP 

Operational  Capability 

ORB 

Object  Request  Broker 

ORS 

Operationally  Responsive  Space 

PMO 

Program  Management  Office 

QoS 

Quality  of  Service 

R&D 

Research  &  Development 

RPC 

Remote  Procedure  Call 

SATOPS 

Satellite  Operations 

SMC 

Space  and  Missile  Systems  Center 

SOA 

Service  Oriented  Architecture 

SOC 

Satellite  Operation  Center 

SOAP 

Simple  Object  Access  Protocol 

SPO 

System  Program  Office 

SW 

Software 

SWOT 

Strengths,  Weaknesses,  Opportunities,  and  Threats 

UDDI 

Universal  Description,  Discovery,  and  Integration 

UHF 

Ultra-High  Frequency 
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US 

United  States 

USAF 

United  States  Air  Force 

VFT 

Value  Focused  Thinking 

W3C 

World  Wide  Web  Consortium 

WSDL 

Web  Services  Description  Language 

XML 

extensible  Markup  Language 
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